使用所有列都包含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

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

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

有缺点：

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