MySQL 分区表查询没走分区裁剪怎么办

我第一次遇到“分区表明明按月份切了，查询还是很慢”，先怀疑索引，后来发现真正的问题是查询条件没有让优化器推导出明确的分区范围。排查这类问题要分开看两件事：分区裁剪决定扫哪些分区，索引决定进入分区后怎么找行。先看 EXPLAIN 的 partitions 列，再决定是否需要改写 SQL 或补索引。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/

MySQL 分区表为什么会扫描不该扫的分区

分区裁剪的核心很简单：优化器能够证明某些分区不可能有匹配行，就把它们排除。问题通常出在“表按什么切”和“条件按什么筛”没有对齐。例如表按 RANGE(order_date) 分区，查询却把日期列包进一个无法推导的表达式，优化器就可能只能保守地查看更多分区。

-- 先确认分区键、函数和边界，不要凭表名猜分区规则
SHOW CREATE TABLE orders\G;

-- 下面是容易被推导的连续范围条件
SELECT order_id, total_amount
FROM orders
WHERE order_date >= '2025-01-01'
  AND order_date 

这里使用左闭右开的日期范围，既不会重复统计月初，也能直接对应按月边界。若表实际使用的是 RANGE(YEAR(order_date))，则要先理解这个表达式的语义，不能把它当成按天或按月切分。

先用 EXPLAIN 证明到底扫描了哪些分区

不要只看查询耗时来判断分区裁剪。对同一条 SQL 执行 EXPLAIN，重点记录 partitions、type、key 和 rows。官方手册把 partitions 定义为该查询可能匹配记录的分区集合；它列出多个分区，不代表裁剪失败，关键是和全表扫描或无条件版本比较。

-- 用执行计划观察分区集合；这是计划示意，不是实际运行结果
EXPLAIN
SELECT order_id, total_amount
FROM orders
WHERE order_date >= '2025-01-01'
  AND order_date 

四类条件最容易让裁剪失效

第一，过滤列不是分区列。即使普通索引有效，也不能据此推断其他分区没有匹配行。第二，在分区列外层套函数，例如对按 order_date 分区的表写 DATE_FORMAT(order_date, '%Y-%m') = '2025-01'，通常不如直接写日期范围清晰。第三，参数类型或隐式转换让边界变得不明确，日期参数最好使用与列一致的类型。第四，范围本身覆盖了绝大多数分区，优化器保留大范围扫描可能就是合理选择。

如果分区表达式本身使用 YEAR()、TO_DAYS() 或 TO_SECONDS() 等受支持函数，查询仍要围绕实际表达式测试；不能因为“日期条件看起来合理”就断言一定会裁剪。

改写 SQL 后仍然慢，下一步查什么

确认 partitions 已缩小后，再检查每个命中分区内的索引。分区不是索引的替代品：它先减少搜索区域，索引再减少区域内的行访问。此时可以比较 key 是否为空、过滤列是否处在联合索引的有效前缀，并结合真实数据分布重新估算 rows。

生产排查时我会保留改写前后的两份计划，记录分区集合、索引选择和估算行数；不要只凭一次耗时下结论。若 SQL 是动态生成的，还要检查应用层是否把日期范围变成了字符串拼接、函数包裹或过宽的默认区间。

相关问题

partitions 列显示多个分区是不是裁剪失败？

不一定。跨两个月的范围本来就可能命中两个分区。把它和无条件查询的分区集合对比，数量明显减少才是更有意义的证据。

分区裁剪生效但 key 还是 NULL，正常吗？

正常。裁剪和索引是两层优化；先确认分区集合，再根据命中分区内的访问方式决定是否补索引。

把查询改成强制分区名能解决吗？

分区选择可以缩小访问范围，但会把分区知识写进业务 SQL。只有在分区边界稳定且场景明确时才考虑，通用查询优先让条件与分区表达式保持一致。