分区表不直接加速group by，仅当查询能剪枝到少数分区且分区键与where及group by强相关时才有效；否则需全分区扫描，甚至降低性能。
分区表本身不直接加速 GROUP BY，它只在查询能“剪枝”到单个或少数几个分区时才对 GROUP BY 有实质帮助；盲目分区反而增加维护成本和执行计划复杂度。
分区键必须和 GROUP BY + WHERE 条件强相关
分区只有被查询实际“用上”才有价值。如果 GROUP BY 字段和分区键无关（比如按时间分区，却按用户ID分组），SQL Server 仍需扫描全部分区，性能无改善，甚至因元数据开销略降。
- 有效场景示例：
SELECT YEAR(log_time), COUNT(*) FROM logs GROUP BY YEAR(log_time)配合log_time列的范围分区（如按月）——WHERE 隐含了时间范围，且分组粒度与分区对齐 - 无效场景：
SELECT user_id, COUNT(*) FROM logs GROUP BY user_id，哪怕表按log_time分区，也必须全分区扫描 - 关键检查点：执行
SET STATISTICS XML ON后看执行计划中PartitionID是否为常量（表示剪枝成功），还是出现Range: [NULL, NULL]（全分区扫描）
分区方案要支持“先过滤、再分组”的执行路径
SQL Server 的 GROUP BY 性能瓶颈往往不在分组本身，而在分组前的数据量太大。分区的价值是让 WHERE 过滤更高效，从而减少进入分组阶段的行数。
- 建分区函数时，优先选高频、高选择性的过滤字段，例如
dt（业务日期）、region（区域编码），而非低基数或变动频繁的字段 - 分区方案必须绑定到具体文件组，且每个分区对应独立物理文件——否则无法实现 I/O 并行；单文件组多分区等于没分
- 避免“过细”分区：比如按天分 1000 天，会导致 1000 个分区对象，元数据压力大，统计信息难以维护，反而拖慢计划生成
索引必须建在每个分区上，且顺序匹配 GROUP BY
分区表上的索引默认是“对齐索引”（aligned），即按相同分区键划分。但仅分区不够，索引结构仍决定 GROUP BY 走排序流式聚合还是哈希分组。
- 若希望走
Stream Aggregate（最快），索引顺序必须严格匹配GROUP BY字段顺序，并前置WHERE条件字段，例如：WHERE dt >= '2026-01-01' GROUP BY region, category→ 索引应为(dt, region, category) - 不要依赖分区自动带来性能提升：即使表已分区，若没在
(region, category)上建非聚集索引，GROUP BY仍会触发Hash Match或磁盘排序 - 验证方式：查执行计划中
GROUP BY上游节点是否为Index Seek/Scan，且Actual Number of Rows显著小于表总行数
别忽略统计信息更新和 MAXDOP 控制
分区表的统计信息默认只在全局层面收集，各分区内部数据分布可能严重倾斜，导致估算错误、内存授予不足、哈希溢出到 tempdb。
- 对关键大分区表，禁用自动统计更新，改用
UPDATE STATISTICS dbo.YourTable WITH FULLSCAN, NORECOMPUTE定期手动更新 - 超大分区
GROUP BY查询建议显式加OPTION (MAXDOP 2)：并行度太高易引发线程间内存争抢，反而让哈希分组退化为磁盘操作 - 慎用
OPTION (RECOMPILE)：它可解决参数嗅探导致的分区剪枝失败，但会绕过计划缓存，高频查询下 CPU 开销明显上升
真正起作用的从来不是“分区”这个动作，而是分区后能否让 SQL Server 在执行计划里少扫几百万行——这取决于分区键是否被 WHERE 用上、索引是否对得上、统计信息是否准、内存是否够分。漏掉其中任一环，分区就只是徒增管理负担的装饰品。
