小表中列的非聚集索引答案

【问题标题】：Non-clustered index on column in a small table小表中列的非聚集索引
【发布时间】：2012-12-30 21:40:51
【问题描述】：

我有下表，ReportType。该表将永远只有 100 左右的行，并且永远不会被应用程序更新（所以INSERT、UPDATE 或DELETE 性能不是问题）。

Table: ReportType
===========================================================
|  ID (PK)  |  Name  |  ExportFormat  |  SourceDatabase   |
===========================================================

还值得在ExportFormat 上放置一个非聚集索引吗？此列在某些场景和某些报表中用作筛选条件。它根本没有高度选择性（可能只有 10 个不同的值），这表明它不会成为非聚集索引的良好候选者。但是这个表从来没有经历过任何INSERT、UPDATE 或DELETE 操作，所以索引肯定会在这里真正受益（即使只是一点点）？

【问题讨论】：

如果表有记录，那么它经历了一次插入。
“所以肯定索引实际上会在这里受益（即使只是一点点）” - 请记住，每个 NC 索引查找都会导致书签查找以获取剩余的列，除非它是覆盖索引（这是不是你提议的）。所以，不，即使只读取表也不一定有好处。

标签： sql sql-server tsql database-design indexing

【解决方案1】：

根据经验，少于 128 行的表上的索引增加的开销超过了它的价值。尤其是非聚集索引——单个书签查找可能比扫描整个表更广泛。

【讨论】：

感谢您的回答。假设有 150 行……那么在这样的列上添加索引是否值得？
没有硬性规定。就个人而言，在我得到性能问题的实际证据之前，我不会添加索引。那是一个速度变慢的查询计划，或者是一个可重现的测试集，在启用索引的情况下会显着改善。

【解决方案2】：

我不同意你接受的答案。

你说这个表是只读的，所以我看不到创建如下覆盖非聚集索引的缺点。

CREATE NONCLUSTERED INDEX IX 
     ON  ReportType(ExportFormat) INCLUDE(ID,Name,SourceDatabase )

对于如此少量的行，好处可能非常微不足道，但它避免了必须为ExportFormat上的每个查询过滤处理所有行

【讨论】：