分区表没有裁剪怎么办：从条件表达式到分区键排查

我第一次碰到“分区表明明按日期切好了，查询却像是还在扫所有分区”时，先把注意力放在普通索引上，折腾了半天才发现方向错了。分区裁剪解决的是“哪些分区不用访问”，普通索引解决的是“进入某个分区后怎样找行”，两者要分开看。

排查时最有效的顺序是：先看 EXPLAIN 的 partitions，再核对 SHOW CREATE TABLE 里的分区表达式，然后检查 WHERE 条件能否直接约束分区键，最后才看普通索引。只要按这个顺序走，多数“没有裁剪”都能定位到表达式不匹配、类型不一致或分区方式本身不适合当前条件。

先确认问题真的是没有分区裁剪

先不要凭查询耗时判断。对目标 SQL 执行 EXPLAIN，重点看 partitions 列：

EXPLAIN
SELECT order_id, created_at, amount
FROM orders
WHERE created_at >= '2026-02-01'
  AND created_at 

• 只出现 p202602：裁剪已经发生。
• 出现相邻少量分区：先检查查询范围是否跨越边界。
• 列出全部分区：条件没有缩小候选分区，继续查分区表达式与条件。

possible_keys、key 和 rows 仍然重要，但它们不能替代 partitions。我现在会先确认分区集合，再判断每个分区内部是否需要索引优化。

初始化一张可观察的日期分区表

下面用 RANGE COLUMNS 直接按 DATE 列分区。这个设计的好处是边界与查询中的日期常量保持同一类型，排查时更直观。

CREATE TABLE orders (
  order_id BIGINT NOT NULL,
  created_at DATE NOT NULL,
  customer_id BIGINT NOT NULL,
  amount DECIMAL(12,2) NOT NULL,
  PRIMARY KEY (order_id, created_at),
  KEY idx_customer_created (customer_id, created_at)
)
PARTITION BY RANGE COLUMNS(created_at) (
  PARTITION p202601 VALUES LESS THAN ('2026-02-01'),
  PARTITION p202602 VALUES LESS THAN ('2026-03-01'),
  PARTITION p202603 VALUES LESS THAN ('2026-04-01'),
  PARTITION pmax    VALUES LESS THAN (MAXVALUE)
);

真正排查线上表时，不要从记忆还原 DDL，而要直接取实际定义：

SHOW CREATE TABLE orders;

记录三个事实：分区类型是什么、分区键或表达式是什么、每个边界值是什么。只看字段名，不看完整 PARTITION BY，很容易把“按列分区”和“按函数结果分区”混为一谈。

让查询条件直接约束分区键

对上面的 RANGE COLUMNS(created_at)，最稳妥的条件是直接给 created_at 一个半开区间：

SELECT order_id, amount
FROM orders
WHERE created_at >= '2026-02-01'
  AND created_at 

半开区间比“月底 23:59:59”更不容易受列精度影响，也能自然衔接下一个分区边界。若业务传入的是时间戳或字符串，先在应用层把值归一为与分区列兼容的日期常量，不要让分区列在 WHERE 中承担不必要的转换。

容易增加判断难度的写法是把列包进另一个表达式：

-- 表按 created_at 直接分区，却在条件中改成另一个表达式
WHERE DATE_FORMAT(created_at, '%Y-%m') = '2026-02';

这类条件虽然表达了相似业务含义，却未必能被优化器还原为明确的分区边界。改成直接范围后，再用 EXPLAIN 比较 partitions 列，不要只比较耗时。

从分区表达式反查条件写法

不是所有日期分区都写成 RANGE COLUMNS。如果表定义是下面这样，分区值实际是年份整数：

PARTITION BY RANGE (YEAR(created_at)) (
  PARTITION p2025 VALUES LESS THAN (2026),
  PARTITION p2026 VALUES LESS THAN (2027),
  PARTITION pmax  VALUES LESS THAN MAXVALUE
)

MySQL 8.4 官方文档说明，使用 YEAR()、TO_DAYS()、TO_SECONDS() 以及符合条件的 UNIX_TIMESTAMP() 分区表达式时可以进行裁剪。关键不是“条件里必须机械复制分区函数”，而是条件能否让优化器推导出分区表达式对应的常量或范围。

我更倾向先写原始列范围：

WHERE created_at >= '2026-01-01'
  AND created_at 

然后检查 partitions 是否收敛到 p2026。如果历史表使用复杂函数、自定义计算或混合类型表达式，优先考虑重构分区设计，而不是继续叠加 SQL 技巧。复杂表达式会让维护者难以从业务日期反推实际分区边界。

检查分区方式与范围边界

条件写对了也不代表一定只访问一个分区。还要看分区方式是否适合这类查询：

• RANGE / RANGE COLUMNS：适合连续区间，日期范围能自然映射到相邻分区。
• LIST / LIST COLUMNS：适合离散值，等值或 IN 条件更容易缩小集合。
• HASH / KEY：等值条件最清晰；短整数范围有机会转换为有限值集合，但范围过大时可能不裁剪。

MySQL 文档特别指出，HASH 或 KEY 分区的短范围只有在范围大小小于分区数量时才适合这种转换。如果条件覆盖的离散值数量已经不少于分区数，扫描全部分区可能就是合理结果。

还要警惕 MAXVALUE。它本身不是问题，但如果历史数据、未来数据和异常值都涌入同一个兜底分区，查询范围稍微放宽就可能命中它。此时应补齐新的时间分区并检查数据落点，而不是把责任都归给优化器。

用固定清单完成回归检查

我现在处理这类问题会固定保存两份 EXPLAIN：改写前一份、改写后一份。每次只改变一个因素，按下面顺序核对：

1. 用 SHOW CREATE TABLE 确认真实的 PARTITION BY 和边界。
2. 确认 WHERE 约束的是分区键，而不是无关列或无法反推的表达式。
3. 确认字段类型与常量类型兼容，尤其是日期、时间戳、整数和字符串。
4. 用 EXPLAIN 检查 partitions 是否缩小。
5. 裁剪正常后，再看 possible_keys、key 和 rows 优化分区内部访问。

一个容易忽略的结论是：分区裁剪成功不等于查询一定快。如果单个分区仍然很大、过滤列没有合适索引，或者返回行数本来就很多，查询仍可能慢。反过来，查询很快也不代表裁剪正确，测试数据太少时尤其容易误判。

常见问题

EXPLAIN 的 partitions 是 NULL，代表扫描全部分区吗？

先确认表是否真的是用户分区表，以及当前 EXPLAIN 输出格式。对分区表排查时，应结合 SHOW CREATE TABLE 与完整执行计划判断，不能只凭一个 NULL 下结论。

把普通索引加到分区键上就会触发裁剪吗？

不会。裁剪依据分区规则和查询条件推导候选分区；普通索引负责分区内部的行访问。两者可能同时生效，但不是互相替代关系。

显式写 PARTITION 子句能代替裁剪吗？

PARTITION (...) 属于显式分区选择，由 SQL 编写者指定访问哪些分区；裁剪是优化器自动判断。显式选择适合受控运维任务，不应当用来掩盖长期存在的条件或分区设计问题。

日期分区优先选 RANGE COLUMNS 还是 YEAR()？

需要按月、按日维护边界时，直接使用日期列的 RANGE COLUMNS 通常更直观；只关心粗粒度年度边界时，YEAR() 也可以。选择时同时考虑查询粒度、分区维护频率和团队能否清楚理解边界。

最终要记住的不是某条固定 SQL，而是一个判断链：WHERE 条件约束什么值，PARTITION BY 如何把这个值映射到分区，EXPLAIN 最终列出哪些分区。把这三件事对齐，分区裁剪问题通常就不再神秘。