分区表本身不加速 GROUP BY，仅通过 WHERE 条件触发分区剪枝来减少分组数据量；若无分区键过滤或使用函数导致剪枝失效，GROUP BY 仍处理全量数据，性能无提升。
分区表本身不加速 GROUP BY，只靠剪枝减少扫描数据量
分区表对 GROUP BY 没有直接优化能力。它提速的唯一路径是：让 WHERE 条件触发分区剪枝，从而大幅减少参与分组的原始行数。如果查询没带分区键的确定性过滤（比如 WHERE dt BETWEEN '2026-01-01' AND '2026-06-30'），数据库仍会扫描全部分区，GROUP BY 依然要处理全量数据——分区白建。
常见错误现象：
- 按
dt（日期）分区的表，执行SELECT region, SUM(sales) FROM orders GROUP BY region，无WHERE，性能毫无改善 -
WHERE dt = '2026-07-15'能剪枝，但WHERE DATE(dt) = '2026-07-15'会因函数调用失效，无法剪枝
必须配合 WHERE + 分区键才能让 GROUP BY 受益
真正起效的组合是：分区键出现在 WHERE 中，且条件可被优化器静态判定（等值、范围、BETWEEN）。此时剪枝生效，GROUP BY 只在命中分区里运行，数据量可能下降 90% 以上。
实操建议：
- 时间类分区优先用
WHERE dt >= '2026-07-01' AND dt ，别用 <code>WHERE YEAR(dt) = 2026 AND MONTH(dt) = 7 - 多租户场景若按
tenant_id哈希分区，查询必须带WHERE tenant_id = 123才能剪枝 - 复合分区（如 RANGE-LIST）需同时满足两级剪枝条件，否则退化为单级扫描
GROUP BY 字段是否是分区键，完全不影响剪枝效果
分区键和 GROUP BY 字段可以完全不同。例如按 dt 分区、按 region 分组，只要 WHERE dt 剪枝成功，GROUP BY region 就只在几个分区里跑，效率取决于剪枝后剩余数据量，而非分组字段本身。
但要注意：
- 若
GROUP BY字段也高频用于WHERE过滤（如WHERE region = '华东' GROUP BY user_id），应在该字段上单独建索引，或建联合索引(region, user_id)，避免剪枝后仍需排序 - 分区剪枝 + 索引覆盖才是完整链路：剪枝减少数据量，索引避免
Using filesort和临时表 - PostgreSQL 支持
CREATE INDEX ... ON ONLY parent_table为每个分区单独建索引，MySQL 8.0+ 的分区表索引默认全局有效，但实际执行时仅对命中的分区生效
容易被忽略的陷阱：统计信息不准导致剪枝失败
即使写了正确的 WHERE 条件，如果分区表的统计信息陈旧（比如新增了大量数据但没 ANALYZE），优化器可能误判分区边界，选择全分区扫描。这在 PostgreSQL 和 MySQL 8.0+ 中都真实存在。
验证与修复方法：
- 执行
EXPLAIN SELECT ...，检查Partition(s)或partitions列是否只列出预期分区 - PostgreSQL：运行
ANALYZE table_name;；MySQL：运行ANALYZE TABLE table_name; - 某些场景下，显式指定分区名（如
SELECT ... FROM sales_2026 PARTITION (p2026_q3)）可绕过优化器误判，但丧失通用性，慎用
剪枝是否生效，不能靠“建了分区就一定快”来假设，必须每次通过 EXPLAIN 确认实际访问的分区列表。
