sql-server – 列数是否会影响查询性能？

情况2：我有一个包含6列的表,我在where子句中使用4列进行查询.

两种情况下的表现有何不同？

例如我有桌子

table A
{
  b varchar(10),c varchar(10),d varchar(10),e varchar(10),f varchar(10),g varchar(10),h varchar(10)

}

SELECT b,c,d
FROM A
WHERE f='foo'

create table B
{
  b varchar(10),f varchar(10)

}

SELECT b,d
FROM B
WHERE f='foo'

A和B表具有相同的结构意味着在条件也相同且列中的列也相同时使用的列数和列数的差异.区别在于表B只有一些未使用的列,这些列未在select和where条件中使用
在这种情况下,两个查询的性能有任何差异吗？

解决方法

Does the number of columns affect query performance?

是的,因为在SELECT中返回较少列的主要好处是SQL可能能够避免从表/集群中读取,而是,如果它可以从索引中检索所有选定的数据(作为索引列和/或在covering index的情况下包括列.

显然,谓词中使用的列(其中过滤器),即示例中的f,必须位于索引的索引列中,并且必须足够selective,以便首先使用索引.

从SELECT返回较少的列还有一个第二个好处,因为这会减少任何I / O开销,特别是如果数据库服务器和使用数据的应用程序之间的网络速度很慢 – 也就是说,这是一个好习惯.返回您实际需要的列,并避免使用SELECT *.

编辑：回应OP的更新帖子：

如果没有索引,则两个查询都将执行表扫描.鉴于表B的列数少于表A,每页的行数(密度)将在B上更高,因此B将稍微快一些,因为SQL需要获取更少的页面.

但是,索引如下

> A(f)指数包括(b,d)
> B(f)指数包括(b,d)

对于查询,性能应该是相同的(假设两个表中的数据相同),因为SQL将达到现在具有相似列宽和行密度的索引.

编辑

其他一些计划：

> B(f)上的索引,没有其他键或INCLUDE列,或者包含不完整的INCLUDE列(即缺少b,c或d中的一个或多个)：

SQL Server可能需要执行Key or RID Lookup,即使使用了索引,也需要“连接”回表以检索select子句中缺少的列. (查找类型取决于表是否具有聚簇PK)

> B上的直非聚簇索引(f,b,d)

这仍然是非常高效的,因为将使用索引并避免使用表,但是won’t be quite as good as the covering index,因为索引树的密度将由于索引中的附加键列而较少.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!