怎样在SQL Server中优化带有GROUP BY的分页查询？-SQL-PHP中文网

group by 与 offset/fetch 同用会导致性能雪崩，因 sql server 先全量扫描、分组、排序，再分页；需建覆盖索引实现流式聚合，或拆分分页与聚合逻辑，大偏移量必须改用游标分页。

怎样在sql server中优化带有group by的分页查询？

GROUP BY 和分页（OFFSET/FETCH）一起用，基本等于主动触发性能雪崩——除非你提前建对索引、拆开逻辑，或彻底换掉分页方式。

为什么 GROUP BY + OFFSET/FETCH 会慢到查不出结果

SQL Server 不是先分页再分组，而是先全量扫描 WHERE 匹配的所有行 → 全量哈希分组或排序分组 → 再对分组结果排序 → 最后才跳过 OFFSET 行。哪怕你只要第 100 页的 10 条分组，它也可能扫千万行、做千万行的哈希聚合。

典型信号：

执行计划里 Hash Match (Aggregate) 节点的 Actual Number of Rows 是几百万，而最终输出只有几十行
该节点上游是 Clustered Index Scan 或大范围 Index Scan，不是 Index Seek
logical reads 高达数十万甚至上百万（用 SET STATISTICS IO ON 看）

覆盖索引让 GROUP BY 变成流式聚合（Stream Aggregate）

目标是绕过哈希/排序，让 SQL Server 按索引物理顺序“边读边分组”。这要求索引字段顺序和查询结构严丝合缝：

WHERE 条件字段必须是索引最左列（如 status = 'shipped' → 索引首列为 status）
GROUP BY 字段紧随其后，且顺序完全一致（如 GROUP BY region, category → 索引为 (status, region, category)）
SELECT 中的聚合字段（如 SUM(price)）必须 INCLUDE 进索引，否则回表会打断流式路径
避免在 WHERE 或 GROUP BY 中用函数：YEAR(create_time)、UPPER(name) 会让索引失效

示例索引与查询：

CREATE NONCLUSTERED INDEX IX_orders_filter_group 
ON orders (status, region, category) 
INCLUDE (price);

SELECT region, category, SUM(price) 
FROM orders 
WHERE status = 'shipped' 
GROUP BY region, category 
ORDER BY region 
OFFSET 200 ROWS FETCH NEXT 10 ROWS ONLY;