sql-server - 列数会影响查询性能吗？

Question

案例 1:我有一个包含 30 列的表，我在 where 子句中使用 4 列进行查询。

案例 2:我有一个包含 6 列的表，我在 where 子句中使用 4 列进行查询。

这两种情况的性能有何差异？

例如我有 table

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),
  c varchar(10),
  d varchar(10),
  e varchar(10),
  f varchar(10)

}

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

A表和B表结构相同，只是列数不同，where条件中使用的列也相同，select中的列也相同。区别在于表 B 只有一些未使用的列，这些列未在 select 和 where 条件中使用在这种情况下，两个查询的性能有什么区别吗？

Answer 1

Does the total number of columns in a table impact performance (if the same subset of columns is selected, and if there are no indices on the table)

是的，稍微，在根本没有索引的情况下，两个查询(表 A 和表 B)都会进行表扫描。鉴于 Table B 的列数少于 Table A ，因此 B 上的每页行数(密度)会更高，因此 B 的速度会稍快一些，因为需要获取的页面较少。

但是，鉴于您的查询采用以下形式:

SELECT b,c,d
FROM X
WHERE f='foo';

查询的性能将由列 f 上的索引决定，而不是基础表中的列数。

对于OP的精确查询，最快的性能将来自以下索引:

• A(f) INCLUDE (b,c,d) 上的索引
• B(f) INCLUDE (b,c,d) 上的索引

无论表 A 或表 B 中的列数有多少，在使用上述索引的情况下，两个查询的性能应该相同(假设两个表中的行数相同且数据相似)，前提是 SQL 将命中现在索引的列宽和行密度相似，不需要原始表中的任何附加数据。

Does the number of columns in the select affect query performance?

在 SELECT 中返回较少列的主要好处是 SQL 可能能够避免从表/簇中读取，相反，如果它可以从检索所有 selected 数据， >index (在 covering index 的情况下作为索引列和/或包含列)。

显然，谓词(where 过滤器)中使用的列，即示例中的 f ，必须位于索引的索引列中，并且数据分布必须足够 selective ，以便首先要使用索引。

从 SELECT 返回更少的列还有一个次要好处，因为这会减少任何 I/O 开销，特别是当数据库服务器和使用该值的应用程序之间的网络速度较慢时数据 - 即，最好只返回您实际需要的列，并避免使用 SELECT * 。

编辑

其他一些计划:

• 在 B(f) 上建立索引，没有其他键或 INCLUDE 列，或者包含一组不完整的 INCLUDE 列(即缺少一个或多个 b, c or d):

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

• B(f,b,c,d) 上的直接非聚集索引

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