不能——但能大幅减少分组前的数据扫描量，间接让 GROUP BY 快得多；关键在于 WHERE + GROUP BY 字段顺序匹配聚集索引键，避免全表扫描、排序或哈希分组，且需确保无函数、类型转换等干扰索引使用。
聚集索引能直接加速 GROUP BY 吗？
不能——但能大幅减少分组前的数据扫描量，间接让 GROUP BY 快得多。关键不是“GROUP BY 走聚集索引”，而是“WHERE + GROUP BY 的字段顺序刚好匹配聚集索引键”，从而避免全表扫描、排序或哈希分组。
什么时候该把 GROUP BY 字段设为聚集索引键？
当查询模式高度稳定、且分组字段天然具备高选择性或范围特征时才值得。比如按 order_date 分组统计日销量，而 order_date 本身已是聚集索引（或至少是聚集索引最左列）。
- 聚集索引键必须包含所有
WHERE条件字段（尤其是等值条件），再紧接GROUP BY字段 - 如果
WHERE status = 'shipped' AND order_date >= '2026-01-01'，GROUP BY region, category，那理想聚集索引是(status, order_date, region, category) - 不要只为 GROUP BY 单独建聚集索引——每张表只能有一个聚集索引，它决定了数据物理存储顺序，代价很高
- 若已有主键（如
id）是聚集索引，且业务上频繁按时间/区域分组，可考虑将主键改为非聚集，另建以时间/区域开头的聚集索引（需评估写入影响）
为什么 (region, category) 聚集索引对 GROUP BY region, category 不一定快？
因为聚集索引只在满足「连续物理存储」前提下才能跳过排序。如果数据插入无序（比如 region 值来回穿插），即使索引键顺序对了，SQL Server 仍可能在执行计划里出现 Sort 或 Hash Match Aggregate——它发现物理行不连续，无法流式聚合。
- 验证方法：开
SET STATISTICS XML ON，看执行计划中Aggregate上游有没有Sort或Compute Scalar - 真正起效的前提是：WHERE 过滤后剩余行在聚集索引页中尽量连续；否则不如用覆盖型非聚集索引 + INCLUDE
- 高基数字段（如
category）放聚集索引左边会加剧页分裂，尤其在高并发 INSERT 场景下
聚集索引配合 GROUP BY 最容易被忽略的细节
很多人以为建了就完事，其实最关键的一步常被跳过：确保查询里没用函数、类型转换或隐式排序干扰索引使用。
-
GROUP BY YEAR(order_date)会让聚集索引完全失效——哪怕order_date是聚集索引首列，也得改成持久化计算列 + 索引 -
WHERE region = N'East'（N前缀）和region列是varchar类型，会触发隐式转换，聚集索引可能退化为扫描 - 如果
SELECT里用了ORDER BY其他字段（比如ORDER BY total_sales DESC），而该字段不在聚集索引中，仍会额外触发 Sort，聚集索引只解决分组阶段，不解决结果排序
聚集索引对 GROUP BY 的加速效果，本质上依赖于数据分布与查询模式的咬合程度。一旦物理顺序和逻辑分组脱节，再“正确”的索引定义也救不了执行计划里的 Using temporary。
