group by + offset/fetch 分页变慢是因为sql server需全量分组、排序后才分页，导致逻辑读暴增；应建覆盖索引实现流式聚合，或拆分分页与聚合步骤，并及时更新统计信息。
GROUP BY 本身不优化分页，反而是分页查询里混用 GROUP BY 容易让性能雪上加霜——尤其当分页基于聚合结果时，SQL Server 往往被迫先全量分组、再排序、最后取页，执行计划里频繁出现 Hash Match Aggregate 和 Sort 节点，逻辑读暴增。
为什么 GROUP BY + OFFSET/FETCH 分页会变慢
SQL Server 的 OFFSET ... FETCH 是在最终结果集上跳过行数，而 GROUP BY 输出的是聚合后的新行集。如果没索引支撑，数据库必须：
- 扫描所有匹配 WHERE 的原始行（哪怕只想要第100页的10条分组）
- 对全部中间结果做哈希分组或排序分组
- 再对分组结果排序（若含 ORDER BY）
- 最后才应用 OFFSET/FETCH —— 此时已无法剪枝原始数据
典型症状：执行计划中 Actual Number of Rows 在 GROUP BY 节点远高于预期（比如千万级输入，只想要百条分组），且上游是 Clustered Index Scan 或 Index Scan。
用覆盖索引把 GROUP BY 变成流式聚合（Stream Aggregate）
目标是让 SQL Server 走 Index Seek → 直接按索引顺序流式分组，避免哈希/排序。关键在索引字段顺序和覆盖性：
- WHERE 条件字段必须最左（如
status = 'active'） - GROUP BY 字段紧随其后，且顺序完全一致（如
GROUP BY region, category→ 索引为(status, region, category)） - SELECT 中的聚合字段（如
SUM(price)）必须INCLUDE进索引，否则回表会打断流式路径 - 避免在 GROUP BY 或 WHERE 中用函数，
GROUP BY YEAR(create_time)或WHERE UPPER(name) = 'ABC'会让索引失效
示例索引：
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;
替代方案：先分页分组键，再 JOIN 补全聚合值
当 GROUP BY 字段基数不高（如 region 只有 10 个值），但聚合计算重（如要算 5 个不同指标），可拆成两步：
- 第一步：仅查分组键 + 计数（轻量），用
OFFSET/FETCH分页 - 第二步：用这些键批量 JOIN 原表或预聚合表，补全其他聚合字段
这样避免每次分页都重复跑全量聚合。例如：
WITH top_regions AS ( SELECT region FROM orders WHERE status = 'shipped' GROUP BY region ORDER BY COUNT(*) DESC OFFSET 200 ROWS FETCH NEXT 10 ROWS ONLY ) SELECT r.region, COUNT(*) cnt, SUM(o.price) total FROM top_regions r JOIN orders o ON r.region = o.region AND o.status = 'shipped' GROUP BY r.region;注意：JOIN 条件里必须复现原始 WHERE，否则统计失真。
别忽略统计信息和 MAXDOP 设置
即使索引结构完美，过期的统计信息也会让优化器误判数据分布，选错执行计划（比如该走 Seek 却选了 Scan）。分区表尤其敏感：
- 定期更新统计信息：
UPDATE STATISTICS orders WITH FULLSCAN, NORECOMPUTE; - 高并发分页场景下，
MAXDOP 1有时比并行更稳——并行分组容易触发内存溢出，降级到磁盘临时表 - 检查执行计划中 GROUP BY 上游是否为
Index Seek，且Estimated Number of Rows接近实际过滤后行数；若差 10 倍以上，大概率是统计信息滞后
真正卡住的往往不是语法写法，而是索引字段顺序错一位、INCLUDE 少一个字段、或者统计信息三个月没更新——这些细节在执行计划里都藏得极深，但改完立刻见效。
