SQL Server中GROUP BY后出现Sort算子说明索引未覆盖查询路径；必须按WHERE等值列→GROUP BY列→范围条件顺序创建复合索引，INCLUDE仅避免回表且不参与排序。
GROUP BY后出现Sort算子，说明索引没真正覆盖
SQL Server不会因为建了app_account单列索引就跳过排序。执行计划里只要看到红色的Sort算子，就代表它正在把所有匹配行拉进内存做物理重排——这和有没有索引无关，只和索引能否让数据“天然按GROUP BY字段顺序存放”有关。
常见错误是只看Index Seek就以为优化成功。但Index Seek后面如果跟着Sort，逻辑读可能翻几倍，CPU时间飙升。必须用SET STATISTICS IO ON实测逻辑读，不能信“用了索引”这个表象。
覆盖索引字段顺序必须严格匹配WHERE + GROUP BY路径
索引不是堆字段就行，顺序错一个位置，整个覆盖就失效。核心规则只有一条：WHERE等值条件列放最左，GROUP BY字段紧随其后，范围条件（如createdate > '2025-01-01'）必须放最后。
- 查询是
SELECT app_account, COUNT(*) FROM t WHERE status = 1 GROUP BY app_account→ 索引必须是(status, app_account) - 如果还带
AND createdate > '2025-01-01'，索引得写成(status, createdate, app_account)，否则app_account无法利用索引顺序 -
(app_account, status)或(status, app_account, createdate)都无效——前者无法加速WHERE status = 1，后者让app_account失去有序性
INCLUDE列只能避免回表，不能参与排序或过滤
INCLUDE列的作用非常窄：仅当SELECT里有非聚合字段（比如MAX(name)）时，把它加进来可省一次回表。但它完全不参与WHERE判断、不参与GROUP BY分组、也不影响排序顺序。
- 错误用法：
CREATE INDEX IX_t ON t (status) INCLUDE (app_account)——app_account在INCLUDE里，无法用于分组，Sort照常出现 - 正确用法：
CREATE INDEX IX_t_cover ON t (status, app_account) INCLUDE (name)—— 分组靠前两列顺序，name只是投影用，不增加排序负担 - 别滥用
INCLUDE：每多一列，索引体积和维护成本都涨，INSERT/UPDATE延迟明显上升
ORDER BY NULL在SQL Server中基本没用
MySQL里ORDER BY NULL能明确压制隐式排序，但SQL Server压根没有这个语义。它既不默认按GROUP BY字段排序，也不会因你写了ORDER BY NULL就跳过Sort算子——执行计划里该有Sort还是有。
真正有效的只有两条路：
- 确保索引字段顺序严格匹配
GROUP BY子句，让数据物理有序 - 如果结果确实需要排序（比如报表输出），就老老实实写
ORDER BY app_account，并确认该字段已在索引最右连续位置（如(status, app_account)）
最容易被忽略的是：哪怕GROUP BY字段本身上了索引，只要查询里带WHERE条件或SELECT其他字段，那个单列索引就大概率被优化器弃用——它没法同时扛住过滤、分组、投影三件事。
