SQL Server查询优化：sum case when比count+where更快原因及方案问询

问题1：是否sum case when的写法天生比count+where筛选的写法速度更快？ #

不是，本次性能差异和sum(case when)语法本身无关，核心是两个查询的逻辑差异导致了执行计划效率不同：

• 原查询对left join得到的d1、d2、d3字段加了where过滤条件，相当于把左连接隐式转为内连接，优化器在多表连接+多维度过滤的场景下很容易出现行数预估错误，选错连接顺序或连接算法，导致执行效率低下。
• 改写后的查询仅在where中保留了d0表的过滤条件，后续校验全部放到了sum的逻辑判断中，优化器可以优先过滤出d0表中符合条件的小数据集再做后续连接，中间处理的数据量大幅减少，才是性能提升的核心原因。

问题2：两张执行计划中更快的是第二张，我该如何提示查询优化器选择性能更优的执行计划？ #

最稳定的方案是用SQL Server自带的**查询存储（Query Store）**功能，找到对应慢查询的执行计划，直接选择「强制计划」即可，不需要修改SQL代码，也不会因为后续版本升级失效。
如果需要用查询提示实现，可选两种方案：

• 简单场景可以加OPTION (FORCE ORDER)提示，强制优化器按照你写的表连接顺序执行，避免优化器乱调整连接顺序，适用场景是你确定当前的连接顺序是最优的。
• 极端场景可以用USE PLAN N'[执行计划XML]'提示，把快的执行计划XML直接粘贴进去，不过这个方案非常脆弱，表结构、索引变更后就会失效，不推荐长期使用。

问题3：索引的列顺序是否会影响本次查询性能？ #

会直接影响。
你当前的聚集索引顺序是key_v → key_t → n_value → value，而本次查询优先过滤的是n_value=0和value=100，这两个字段在索引的第三、第四位，前面的key_v、key_t没有任何过滤条件，所以查询只能走全索引扫描，无法用到更高效的索引查找。
如果要进一步优化该查询，可以把聚集索引调整为n_value → value → key_v → key_t的顺序，这样d0表的过滤可以直接走索引查找，定位到所有符合条件的行，性能还能进一步提升，但调整聚集索引前要评估其他业务查询的使用场景，避免顾此失彼。

问题4：原查询写法符合常规逻辑，我是应该新增索引让其匹配更优执行计划，还是直接使用改写后的第二条查询？ #

优先选择改写后的第二条查询：

1. 改造成本最低，已经可以把执行时间从12s降到2~3s，满足绝大多数性能需求。
2. 不需要额外新增索引，避免增加数据写入时的索引维护开销，也不会影响其他查询的执行计划。
   如果后续该查询还有性能提升需求，或者业务中存在大量同类结构的查询，再评估新增覆盖索引或者调整索引顺序即可，没必要为了兼容原SQL的写法单独做索引优化，收益极低。

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