group by 慢主要因无法利用索引导致临时表（worktable/workfile）和排序开销；优化需按“过滤→关联→分组”顺序建覆盖索引，并注意基数倾斜、distinct 替换限制及 order by 额外排序成本。
GROUP BY 为什么慢？先看执行计划里的 Using temporary
SQL Server 执行 GROUP BY 时，如果无法利用索引完成分组和排序，就会在内存或磁盘上创建临时工作表（Worktable 或 Workfile），对应执行计划中常出现 Hash Match (Aggregate) 或带 Sort 的 Stream Aggregate。这正是你看到 30 秒变 0.5 秒前最典型的瓶颈信号。
从真实案例看，PAGEIOLATCH_SH 等待占比极高，说明大量物理读发生在分组过程中——不是数据没缓存，而是分组逻辑被迫反复扫描、排序、写临时页。
- 检查方法：运行
SET STATISTICS IO ON+ 查询，重点关注logical reads是否远超表本身大小（比如 Orders 表 5000 万行，但逻辑读达千万级） - 确认是否触发临时表：在执行计划里搜索
Worktable或看Warnings标签页是否有Warning: Operator used tempdb - 别被“索引已存在”骗了：即使
CustomerID有索引，但GROUP BY o.CustomerID, c.CustomerName, c.City是跨表三字段，原索引大概率不覆盖
建什么索引才真正加速 GROUP BY？联合索引顺序很关键
对 GROUP BY 最有效的索引，不是单列，也不是随便拼的联合索引，而是按「过滤 → 关联 → 分组」顺序排列的覆盖索引。
以原始查询为例：WHERE o.OrderDate BETWEEN @StartDate AND @EndDate AND o.Status IN ('Completed','Shipped') + JOIN Customers + GROUP BY o.CustomerID, c.CustomerName, c.City，最优索引应为：
CREATE INDEX IX_Orders_DateStatus_CustomerID_Incl ON Orders (OrderDate, Status, CustomerID) INCLUDE (Amount);
-
OrderDate和Status放前面：满足WHERE条件的范围扫描，越早缩小数据集，后续分组压力越小 -
CustomerID紧跟其后：让扫描结果天然按分组键有序，避免额外Sort -
INCLUDE (Amount)：把聚合需要的字段带上，避免回表，直接支持SUM(o.Amount) - Customers 表上必须有
CustomerID主键或唯一索引（已有），且CustomerName, City字段要加到INCLUDE或建单独索引，否则 JOIN 后仍需查找
GROUP BY 和 DISTINCT 在某些场景下真能互换？但得小心语义陷阱
当你的目标只是“列出所有满足条件的客户组合”，而不需要每个组的聚合值（比如 COUNT(*)、SUM()），用 DISTINCT 替代 GROUP BY 可能快一个数量级——因为 SQL Server 对 DISTINCT 更倾向用 Sort + 去重，而非构建哈希桶或临时表。
但注意：这不是通用解法，仅适用于“无聚合、纯去重”的等价场景。
- 安全替换条件：SELECT 列全是
GROUP BY字段，且没有COUNT/SUM/AVG等聚合函数 - 危险操作：把
SELECT o.CustomerID, COUNT(*) FROM ... GROUP BY o.CustomerID改成DISTINCT o.CustomerID—— 结果完全不同 - 测试发现：某次优化中
GROUP BY耗时 37 秒，改DISTINCT后 0.8 秒，但上线后因业务逻辑依赖COUNT值，导致报表数据错误
ORDER BY 和 GROUP BY 一起用时，索引必须包含排序字段
原始查询末尾有 ORDER BY TotalAmount DESC，这个排序不会复用 GROUP BY 的输出顺序——因为 TotalAmount 是聚合结果，不是原始列。SQL Server 必须额外做一次排序，除非你显式提供支持。
解决办法不是加 ORDER BY NULL（无效），而是让索引覆盖最终排序需求：
- 如果业务允许近似排序，可改用
ORDER BY o.CustomerID DESC（复用索引顺序） - 若必须按
TotalAmount排，且该值变化不大，可考虑计算列 + 索引：ALTER TABLE Orders ADD TotalAmount AS Amount PERSISTED，再建索引 - 更稳妥的做法：把聚合结果插入临时表，再在临时表上建索引并排序——尤其当结果集小于 10 万行时，比强行在大表上扫更快
最容易被忽略的一点：GROUP BY 的性能拐点往往不在数据量本身，而在分组键的**基数分布**。比如 CustomerID 有 200 万不同值，但其中 1% 的客户占了 90% 的订单，这种倾斜会让 Hash Match 效率断崖下跌——这时索引再好也救不了，得靠业务层拆分或预聚合。
