为何调整SQL Server索引列顺序后查询性能骤降？

你遇到的问题核心是误将「区分度优先」当成索引设计的绝对规则，忽略了查询过滤逻辑的优先级，具体原因拆解如下：

1. 查询过滤逻辑与索引顺序完全不匹配 #

你的目标查询逻辑是：

SELECT COUNT(*) 
FROM Table_With_Values 
WHERE FK_ObjectTheValuesBelongTo_Id = 460  -- 等值匹配
AND [From]>=CONVERT([datetime2](3),'07.10.2024 00:00:00',(104))  -- 范围过滤
AND [To]<=CONVERT([datetime2](3),'08.10.2024 00:00:00',(104))  -- 范围过滤

• 原索引将FK_ObjectTheValuesBelongTo_Id（等值条件）放在首位：SQL Server可以直接通过索引快速定位到所有属于ID=460的对象的数据，这个子集规模远小于全表；之后再在这个小范围内过滤日期条件，数据扫描量极小，效率自然很高。
• 修改后的索引将[From]（范围条件）放在首位：SQL Server需要先扫描所有符合日期范围的数据，再逐一检查这些数据的FK_ObjectTheValuesBelongTo_Id是否等于460。由于日期范围覆盖的数据量远大于单对象的数据量，扫描和筛选的成本直接飙升，导致执行时间暴涨。

2. 对「区分度优先」规则的适用场景误解 #

SQL Server文档中「按列的区分度排序」的建议，仅适用于多个等值过滤条件并存的场景：此时区分度高的列放在前面，能更快缩小数据集。但当查询中同时存在等值条件和范围条件时，等值条件必须放在范围条件之前——这是索引顺序设计的核心优先级规则，优先级远高于区分度。

3. 现有表结构的额外影响 #

你的表中已存在唯一索引Uq_TableWithValues_ObjectTheValuesBelongTo_Id_From，该索引的列顺序（外键+From）其实也能被原查询高效利用：定位到单对象数据后，结合From的范围过滤，再通过键查找或覆盖索引完成To的验证（如果原非聚集索引是覆盖索引则更优）。修改后的索引完全偏离了这个高效路径，进一步放大了性能差距。

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