MySQL 怎样从执行计划判断分区裁剪

MySQL 分区表查询慢时，我通常先看 EXPLAIN 的 partitions，而不是先猜索引。这个字段列出当前计划可能匹配的分区：只出现目标分区，说明优化器已经把不可能命中的分区裁掉；分区名几乎全部出现，则说明这条查询没有获得明显的分区裁剪。它描述的是计划范围，不是实际耗时证明。

本文限定 MySQL 8.4，只讨论分区裁剪条件与执行计划证据，不延伸到分区数量设计或压测结论。官方文档：https://dev.mysql.com/doc/refman/8.4/en/partitioning-pruning.html

判断顺序可以固定成四步：先看分区表达式，再看 WHERE 是否给出可推导的常量范围，然后读 partitions，最后才结合 rows、索引和实际业务指标。

先把分区边界和查询条件对齐

分区裁剪的核心是“不会命中的分区不扫描”。例如按月份使用 RANGE COLUMNS(order_day) 分区时，查询若直接给出起止日期，优化器就有机会把条件映射到有限的月份分区。等值、IN 列表和可缩小的短范围，都是较容易分析的形式。

-- 只在隔离测试表上展示分区边界；不要覆盖已有业务对象
CREATE TABLE order_event_demo (
  id BIGINT NOT NULL,
  order_day DATE NOT NULL,
  amount DECIMAL(10, 2) NOT NULL,
  PRIMARY KEY (id, order_day)
) ENGINE = InnoDB
PARTITION BY RANGE COLUMNS (order_day) (
  PARTITION p2025_01 VALUES LESS THAN ('2025-02-01'),
  PARTITION p2025_02 VALUES LESS THAN ('2025-03-01'),
  PARTITION p2025_03 VALUES LESS THAN ('2025-04-01'),
  PARTITION pmax VALUES LESS THAN (MAXVALUE)
);

-- 用半开区间表达一个月，便于与分区上界直接对应
SELECT id, amount
FROM order_event_demo
WHERE order_day >= '2025-02-01'
  AND order_day 

这个条件只表达一个明确的日期区间，预期能让计划关注 p2025_02。这里的“预期”是根据分区定义推导的说明，不是本文在某个数据库实例上执行得到的回执。

EXPLAIN 里先看 partitions 字段

对同一条查询加上 EXPLAIN，重点看输出中的 partitions。官方定义是“记录可能匹配的分区”；非分区表则为 NULL。当输出只列出 p2025_02，它是分区裁剪的直接计划证据。

-- 读取传统执行计划；输出中的 partitions 是判断入口
EXPLAIN
SELECT id, amount
FROM order_event_demo
WHERE order_day >= '2025-02-01'
  AND order_day = '2025-02-01'
  AND order_day 

可以用下面的静态示意理解结果列，但不要把示意数字当作执行回执：

table             partitions     type   key        rows   filtered
order_event_demo  p2025_02       range  PRIMARY    1200   100.00

如果 partitions 变成 p2025_01,p2025_02,p2025_03,pmax，通常说明谓词无法缩小候选分区，或查询范围本来就覆盖了它们。若只有部分分区出现，才说明发生了裁剪；分区名数量少不代表查询一定快，还要看每个分区中的数据量和后续过滤。

不要把 key、rows 和 partitions 混为一谈

partitions 回答“查哪些分区”，key 回答“选了哪个索引”，rows 是优化器估计要检查的行数，filtered 是条件过滤比例。四者可能同时变化，但没有一个可以替代另一个。

因此，看到 key = PRIMARY 不能证明分区裁剪；看到 type = ALL 也不能单独证明没有裁剪。分区裁剪和分区内访问方法是两层判断，先看候选分区，再看分区内部是否使用索引。

函数和宽范围会让裁剪证据变弱

最常见的误判是对分区列做函数包装后，仍期待优化器按原边界精确裁剪。例如按日期分区时，WHERE YEAR(order_day) = 2025 是否能被当前分区表达式完整推导，不能只凭直觉判断；更稳妥的写法是按分区边界改成日期半开区间，并重新查看 partitions。

-- 将整年条件改写成明确的半开范围，避免把判断交给不透明函数
SELECT id, amount
FROM order_event_demo
WHERE order_day >= '2025-01-01'
  AND order_day = '2025-01-01';

参数化 SQL 也要结合实际计划观察：如果优化器无法在准备阶段得到足够的边界信息，partitions 可能比字面量查询更宽。不要为了得到一份漂亮的计划而关闭参数化；应在真实驱动方式下比较计划，并记录版本、绑定类型和查询范围。

分区裁剪是不是越多越好？

不是。裁剪只说明排除了不可能命中的分区；若业务查询本来就是跨年报表，访问多个分区是合理结果。真正需要处理的是谓词范围与业务目标不匹配，或在只查一个月时却列出所有分区。

为什么 partitions 只有一个，查询仍然慢？

这表示分区层面范围较小，不代表分区内部没有大量行，也不代表索引、排序、回表和下游处理都高效。继续看 key、rows 和真实负载，但不要把它们重新当作裁剪证据。

我的排查顺序是：保存分区定义，确认 WHERE 与分区表达式的关系，查看 EXPLAIN 的 partitions，再解释索引和行数估算。只有当查询目标明确却始终列出全部分区时，才值得继续改写谓词或检查分区设计；不要用增加分区数量替代证据。