表有很多列时的 SQL Server 性能答案

【问题标题】：SQL server performance when table has many columns表有很多列时的 SQL Server 性能
【发布时间】：2017-08-02 08:08:05
【问题描述】：

我的问题是关于 SQL Server 表的性能。

假设我有一个包含许多列的表，例如 30 列，其中 1 列被索引。该表大约有 30,000 行。

如果我执行一个选择索引列的选择，以及另外一个，例如：

SELECT IndexedColumn, column1
FROM table

这会比在只有 2 列的表上执行相同的选择并执行 SELECT * ... 慢吗

所以基本上，如果我不从额外列中检索数据，额外列的存在会减慢选择查询事件的速度吗？

【问题讨论】：

如果column1 不是您的索引的一部分，那么没有WHERE 的SELECT 将根本不会使用该索引。它必须使用聚集索引，是的，扫描 30 列的聚集索引比扫描 2 列中的一个要慢。也就是说 - 任何足够强大的服务器将在可能可以忽略不计的时间内扫描 30.000 行的任何内容，所以除非您每秒多次选择所有行，您不太可能注意到。如果column1 是索引的一部分（即，它正在覆盖），则不会命中聚集索引，并且表中的列数无关紧要。考虑INCLUDE。
Eric Lippert 写的不错performance rant

标签： sql-server

【解决方案1】：

由于您不必为最终客户端（SSMS 或其他应用程序）打印/传递其余信息，因此在流程的最后会有细微差别。

在基于聚集索引执行读取时，所有列（不含 BLOB）都保存在同一页集上，因此要读取数据，您无论如何都必须访问同一页集。

如果您在所关注的列列表上有一个非聚集索引，您会看到性能提升，因为它们会保存在自己的数据页结构中（因此阅读量会减少）。

【讨论】：

【解决方案2】：

假设您在两种方案中定义表上的主键时都使用 SQL 服务器创建的默认聚集索引，那么不，这两种方案之间不应该有任何性能差异。也许值得只是检查一下并生成一个实际执行计划以供您自己查看？ -- 实际上不确定上述是否正确，因为这是行存储，第一个表将无法在每个页面上容纳尽可能多的行，因此在读取数据时将遭受更多的 IO/磁盘开销。

【讨论】：