SQL Server未自动选用非聚集索引的原因及优化咨询

为什么SQL Server不自动选用索引？ #

核心原因：书签查找的成本预估偏差 #

你创建的tbl_idx是非聚集索引，仅包含field_TIMESTAMP和聚集索引键（id）。执行SELECT *时，SQL Server需要先通过索引找到符合时间条件的行，再通过id回表（书签查找）获取所有列数据。

优化器会预估回表成本：若时间范围筛选出的行数占总数据量比例较高（通常超过20%-30%），优化器会判定全表扫描比「索引+回表」更高效。但实际强制索引后性能飙升，说明优化器的成本预估出现错误——即便更新了统计信息，也可能因为数据分布特殊（比如时间字段的热点数据集中、统计采样无法精准反映真实数据密度），导致它误判了索引的实际价值。

其他影响因素 #

• SELECT *需要返回大量列，非聚集索引无法覆盖查询，回表开销被优化器高估
• field_QUALITY >=192的筛选条件增加了判断复杂度：优化器需要计算时间范围与质量条件的联合筛选率，若统计信息无法精准体现这个联合分布，就会误判索引的性价比

如何优化查询与索引？ #

1. 创建覆盖索引（优先推荐） #

如果你查询的列固定（或常用列明确），创建包含所有查询所需列的非聚集索引，彻底避免回表操作：

CREATE NONCLUSTERED INDEX tbl_covering_idx 
ON tbl (field_TIMESTAMP ASC)
INCLUDE (field_ID, field_VALUE, field_QUALITY /* 其他你需要查询的列 */);

若确实需要SELECT *，可以把所有列加入INCLUDE（注意控制索引体积，避免影响写入性能）。从你更新后的观察来看，包含所需列的索引会被自动选用，这说明覆盖索引是解决问题的核心。

2. 优化过滤索引的实用性 #

你已创建过滤索引tbl_filter_timestamp_idx，但要让优化器自动识别它，需要保证查询的过滤条件与索引完全匹配，且查询列能被索引覆盖。比如针对常用查询调整索引：

CREATE NONCLUSTERED INDEX tbl_filter_covering_idx 
ON tbl (field_TIMESTAMP ASC)
INCLUDE (field_VALUE)
WHERE field_QUALITY >= 192;

这样索引既匹配过滤条件，又无需回表，优化器更容易判定它的成本优势。

3. 避免SELECT *，明确指定查询列 #

尽可能列出需要的列，而非用SELECT *。这不仅能减少数据传输量，还能缩小覆盖索引的体积，让优化器更倾向于选择索引扫描而非全表扫描。

4. 调整索引键列顺序 #

如果field_QUALITY >=192的筛选率极低（符合条件的行很少），可以把field_QUALITY作为索引第一键列，field_TIMESTAMP作为第二键列：

CREATE NONCLUSTERED INDEX tbl_quality_timestamp_idx 
ON tbl (field_QUALITY ASC, field_TIMESTAMP ASC)
INCLUDE (/* 所需列 */);

这样优化器可以先通过field_QUALITY筛选出少量符合条件的行，再用时间范围进一步过滤，大幅减少后续处理量。

关于你更新后的观察 #

你提到「相关查询无论WHERE子句是否包含field_QUALITY，仍未使用任何索引」，核心原因还是这些查询需要回表，优化器预估回表成本过高。解决办法就是给这类查询创建对应的覆盖索引，让索引包含所有查询所需列，优化器会自动选择索引扫描。

内容的提问来源于stack exchange，提问作者Timm