使用所有列都包含INCLUDE的索引是否正确？

Question

在调试SQL查询时，SQL Server Dev Studio建议我必须创建如下索引：

CREATE INDEX IX_MY_INDEX ON T_EVENT (F_ORIGINAL_ID, F_EVENT_SEQUENCE_NO) 
     INCLUDE (F_USER_ID,  F_REVISION_NO, ... <about 30-40 columns>)

因此，在INCLUDE建议包含大量的列。

尽管我确实知道在main index子句中使用所有列是一个糟糕的设计，但是在INCLUDE使用所有字段的缺点是什么？ 还是在INCLUDE之后有很多列的索引完全可以（在性能和优化方面）？

Answer 1

缺点是存储和维护。 每当基础数据发生更改时，数据将被复制并更新索引。 好处是索引将避免在计划中查找键，以便检索查询所需的其他列。

请记住，该索引只是建议，而不是建议。 最好将现有的聚集索引更改为非聚集索引（也许通过选择性地包含列来优化查询），并使建议的索引成为聚集索引。 是否合适取决于您的工作量和查询组合。 一个好的索引策略需要一种整体方法，而不是专注于单个查询/索引。

Answer 2

本质上，这就是聚集索引的作用。 因此，如果表没有聚簇索引，则可以使用索引的相关列来创建一个。

将所有列都包括在内是个好主意吗？ 我想说，作为一般惯例 ，这不是一个好主意。 但是肯定有一些特定的情况是有用的。 基本上，索引是表上所有查询的覆盖索引。 因此，如果使用索引，则没有对数据页的引用。

有缺点：

• 插入，更新和删除速度较慢。 即使对非索引键的更新也会影响索引。
  • 索引“等于”表（实际上有点大，因为索引中有额外的开销）。
• 较大的索引在维护数据库方面具有级联效应，例如更长的备份/恢复和更长的碎片整理。