GROUP BY没走索引需先验证执行计划是否真正利用索引：用SET STATISTICS IO ON和TIME ON查逻辑读与CPU时间，重点观察是否有Sort算子；若存在，说明未避免排序，单列索引无效，应建覆盖索引（WHERE等值列+GROUP BY列+INCLUDE非聚合列），并检查统计信息是否过期或索引碎片是否超标。
GROUP BY没走索引？先确认执行计划里是否真用了索引
SQL Server 2019 的查询优化器不会自动为 GROUP BY 字段“配”索引——它只会在实际能跳过排序、直接利用索引物理顺序时才用。常见误区是：建了单列索引就以为 GROUP BY app_account 肯定快，但若查询还带 WHERE status = 1 AND createdate > '2025-01-01'，而索引是 (app_account) 单列，那大概率会回表+排序，逻辑读飙升。
实操建议：
- 用
SET STATISTICS IO ON+SET STATISTICS TIME ON看实际逻辑读和 CPU 时间，别信“用了索引”这个表面判断 - 在执行计划中重点看是否有
Sort算子；有，说明没避免排序，索引没被高效利用 - 如果
GROUP BY字段选择性低（比如只有 5000 个不同值分布在 500 万行里），单列索引效果有限，优先考虑覆盖索引
GROUP BY太慢，试试覆盖索引而不是只建单列索引
覆盖索引的核心是让 SQL Server 不用回表就能完成分组——即把 GROUP BY 字段 + 所有 SELECT 中的非聚合列 + WHERE 条件列全塞进一个索引里。例如：SELECT app_account, COUNT(*) FROM t WHERE status = 1 GROUP BY app_account，对应索引应为：CREATE INDEX IX_t_cover ON t (status, app_account) INCLUDE (其他 SELECT 中用到的列)。
注意点：
-
INCLUDE列不能用于WHERE或GROUP BY，只用于避免回表取值 - 复合索引字段顺序必须匹配：
WHERE等值条件列优先，再是GROUP BY列；范围条件（如createdate >= '2025-01-01'）要放最后，否则后续列无法走索引查找 - 别盲目加太多
INCLUDE列，每多一列都增加索引体积和维护成本，尤其影响INSERT/UPDATE
GROUP BY + ORDER BY NULL 真的有用吗？要看场景
ORDER BY NULL 的作用是显式告诉优化器“我不需要结果有序”，从而跳过隐式排序。但它只在两种情况下生效：一是索引本身已按 GROUP BY 字段物理排序，二是优化器原本打算加 Sort 但发现没必要。如果执行计划里本来就没有 Sort，加了也白加；如果本就有 Sort 但因为 WHERE 条件打乱了顺序，ORDER BY NULL 也救不了。
更现实的做法：
- 先用
SET STATISTICS IO ON对比加/不加ORDER BY NULL的逻辑读差异，没变化就别加 - 如果
GROUP BY字段本身就是聚集索引键（比如主键），且没其他WHERE条件干扰顺序，那ORDER BY NULL可能省掉一次排序开销 - 别迷信客户端工具显示的时间——像 SQLyog 曾被证实会缓存或改写查询逻辑，务必在 SSMS 或
sqlcmd直连服务器验证
GROUP BY性能突然变差？检查索引碎片和统计信息
即使索引结构完全正确，GROUP BY 查询也可能某天变慢。常见原因是统计信息过期或索引严重碎片化。SQL Server 依赖统计信息估算分组后行数，若统计不准，优化器可能选错执行计划（比如该走索引查找却选了扫描）；而高碎片索引会导致大量随机 I/O，物理读暴增。
排查步骤：
- 运行
DBCC SHOW_STATISTICS ('t', 'IX_t_cover')查看ModificationCounter，若远大于表总行数 20%，说明统计信息很可能过期 - 用
sys.dm_db_index_physical_stats检查avg_fragmentation_in_percent，超过 30% 建议REORGANIZE，超过 60% 建议REBUILD - 更新统计信息别只用
sp_updatestats，对关键表显式执行UPDATE STATISTICS t WITH FULLSCAN，尤其当数据分布倾斜严重时
索引不是建完就一劳永逸的，GROUP BY 性能拐点往往藏在统计信息滞后、碎片增长、或查询参数导致优化器“误判”这三处。最危险的是看到执行计划里标着“已使用索引”，就以为万事大吉。
