MySQL 分区表裁剪失效时的条件改写

分区表裁剪失效时，先别急着重做分区。多数问题出在 WHERE 条件没有让优化器看见“分区键的可推导范围”：列被函数包住、参数发生隐式类型转换，或者多个 OR 分支跨越了无法快速判断的边界。稳定的改写方向是把条件还原成分区表达式可以识别的等值、IN 或范围条件，再用 EXPLAIN PARTITIONS 观察访问范围。

本文以 MySQL 8.4 的分区裁剪语义为边界，只讲条件改写和判断方法；图中结构均为原创静态说明图，不是运行截图。

先确认分区表达式与查询条件是否同一条语义链

在高数据量表上，原架构通常是“按月份或年份分区 + 业务时间查询”。规模上来后，真正的瓶颈不一定是单分区索引，而是优化器无法排除无关分区，导致每个分区都要参与后续过滤。MySQL 的裁剪目标很明确：当条件能化简为分区列等于常量、位于常量列表，或落在可推导的范围内，就可以跳过不可能命中的分区。

先看建表语句，不要只看列名。下面两张表的改写起点不同：

-- 方案一：分区表达式是原始日期列，查询应给出连续日期边界
CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    order_date DATE NOT NULL,
    amount DECIMAL(12, 2) NOT NULL
) PARTITION BY RANGE COLUMNS (order_date) (
    PARTITION p2025 VALUES LESS THAN ('2026-01-01'),
    PARTITION p2026 VALUES LESS THAN ('2027-01-01'),
    PARTITION pmax VALUES LESS THAN (MAXVALUE)
);

-- 方案二：分区表达式是 YEAR(order_date)，条件要能推导出年份
CREATE TABLE yearly_orders (
    id BIGINT PRIMARY KEY,
    order_date DATE NOT NULL
) PARTITION BY RANGE (YEAR(order_date)) (
    PARTITION y2025 VALUES LESS THAN (2026),
    PARTITION y2026 VALUES LESS THAN (2027),
    PARTITION ymax VALUES LESS THAN MAXVALUE
);

关键点是：分区键、分区表达式和查询条件必须处在同一条可推导链上。按 RANGE COLUMNS(order_date) 分区时，直接比较日期范围最自然；按 YEAR(order_date) 分区时，年份边界才是优化器更容易识别的对象。

旧写法为何把裁剪机会藏起来

最常见的写法是把分区列放进格式化函数：

-- 反例：函数包住分区列，条件不再直接暴露日期边界
SELECT id, amount
FROM orders
WHERE DATE_FORMAT(order_date, '%Y-%m') = '2026-03';

它表达的业务意图没有错，但优化器需要先理解函数结果和分区范围的对应关系。更稳妥的做法是把“某个月”写成左闭右开区间：

-- 改写：用半开区间描述整月，避免对分区列逐行格式化
SELECT id, amount
FROM orders
WHERE order_date >= '2026-03-01'
  AND order_date 

半开区间不会把下一月第一天重复算入本月，也适合把结束时间从 23:59:59 改成明确的下一个边界。对 DATETIME 列同样优先用“开始时间包含、结束时间不包含”的写法。

第二类问题是隐式转换，例如分区键是整数却传入带格式的字符串，或日期参数在应用层先转成了不同类型。条件改写不仅要改 SQL，还要让绑定参数类型与分区列一致；否则即使语义相同，也可能让估算和索引选择变得不稳定。

把条件改写成可裁剪的最小表达式

可以把改写规则压缩成三条：

• 原始列分区：优先写 =、IN、BETWEEN 或明确的范围边界。
• RANGE COLUMNS 多列分区：保留前导列的等值约束，再给后续列提供范围，例如 a = 1 AND b 。
• 表达式分区：让条件可化简到分区表达式支持的函数；不要随意把另一个格式化函数套在列外。

-- 多列 RANGE COLUMNS 的示意：先固定前导列，再限制后续列
SELECT id
FROM tenant_events
WHERE tenant_id = 7
  AND event_date >= '2026-03-01'
  AND event_date = '2026-01-01' AND order_date = '2026-06-01' AND order_date 

UNION ALL 不是万能加速器：只有分支互斥、结果不需要去重时才适合。若条件范围本来覆盖大多数分区，拆分反而增加优化和合并成本。条件改写的目标是减少“无法排除”的分区，不是为了让 SQL 看起来更复杂。

用 EXPLAIN PARTITIONS 看裁剪边界

改写后，观察重点不是“有没有分区表”而是访问分区列是否缩小。可以用下面的语句查看优化器计划：

-- 只观察计划，不改变数据；partitions 列用于查看可能访问的分区
EXPLAIN PARTITIONS
SELECT id, amount
FROM orders
WHERE order_date >= '2026-03-01'
  AND order_date 

如果 partitions 只列出目标月份对应的分区，说明裁剪边界已经被识别；如果仍列出全部分区，依次回看分区表达式、参数类型、函数包裹和 OR 范围。即使裁剪成功，也要单独关注分区内索引、回表列、排序和聚合，它们不由分区裁剪自动解决。

上线后的取舍与后续治理

新的条件写法换来了更小的分区访问范围，但代价是应用层必须维护清晰的时间边界，测试也要覆盖月初、月末、时区转换和空范围。分区键一旦选定，主键和唯一键还要符合 MySQL 分区限制；不能因为一次查询变慢，就把所有过滤列都加入分区键。

建议把常用查询按“分区可裁剪、分区内可走索引、结果集可控”三层记录下来。对历史归档、冷热数据和分区维护，再单独评估分区生命周期；不要把分区表当成替代索引的万能开关。

常见问题

把 DATE_FORMAT 改成 YEAR(order_date) 就一定能裁剪吗？

不一定。要先确认建表时就是按 YEAR(order_date) 分区，且当前 MySQL 版本和分区类型支持这种推导。若表按原始日期列或 RANGE COLUMNS 分区，直接使用日期半开区间通常更清晰。

裁剪后查询仍然很慢，说明改写失败了吗？

不一定。裁剪只负责排除不可能的分区；命中分区内部仍可能发生全索引扫描、回表、排序或聚合。先看 EXPLAIN PARTITIONS 的分区范围，再分析分区内访问路径。