MySQL 日期范围查询为什么没有触发分区裁剪

MySQL 日期范围查询没有触发分区裁剪，通常不是“分区失效”，而是优化器无法从当前 WHERE 条件可靠地推导出要访问的分区。先看表的真实分区表达式，再看 EXPLAIN 返回的 partitions 列：如果条件没有直接约束分区键、被不透明函数包住，或者日期范围本身覆盖了大多数分区，就会看到几乎全部分区。

先确认日期列到底怎样参与分区

不要先改 SQL。先执行下面的语句，确认表是按日期列直接分区，还是按 YEAR()、TO_DAYS() 等表达式分区。分区边界决定了优化器能否把日期条件转换成一组明确的分区范围。

-- 先确认分区表达式和每个分区的边界
SHOW CREATE TABLE event_log;

-- 再查看分区名称、边界描述和记录估算
SELECT PARTITION_NAME, PARTITION_METHOD, PARTITION_EXPRESSION,
       PARTITION_DESCRIPTION, TABLE_ROWS
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'event_log'
  AND PARTITION_NAME IS NOT NULL;

例如 RANGE COLUMNS (created_at) 的表，最容易推导的是直接比较 created_at；如果表写成 RANGE (TO_DAYS(created_at))，也要确认查询条件能被当前版本的优化器化为对应的单调范围。表达式、数据类型和边界必须放在一起看。

用 EXPLAIN 判断是没裁剪，还是范围太宽

检查同一条查询的执行计划，重点看 partitions 列。它列出优化器计划访问的分区名称。只命中 p202601、p202602 这样的少量分区，才说明日期范围被缩小了；如果列出 p202601,p202602,p202603 直到最后一个分区，可能是条件跨过了全部边界，也可能是条件无法映射到分区表达式。

-- 用半开区间表达整月范围，避免 DATETIME 的 23:59:59 边界问题
EXPLAIN
SELECT id, created_at, payload
FROM event_log
WHERE created_at >= '2026-01-01 00:00:00'
  AND created_at 

第二种写法把函数放在分区列上，优化器未必能把它还原为分区边界范围。对于按月分区的时间表，优先把日期计算放在常量一侧，保留列的直接比较。即使第一条命中多个分区，也不代表失败：查询跨越三个月时，访问三个分区是正确结果。

四类常见原因对应的处理方式

还要留意 OR、隐式转换和跨分区的宽范围。它们可能让条件变得难以化简。分区裁剪解决的是“少访问哪些分区”，并不替代分区内的索引、过滤和回表优化。

一套稳定的改写与复核清单

把查询改为“开始边界包含、结束边界排除”的形式，例如按天查询就使用 >= 当天零点 和 。然后按以下顺序复核：

1. 重新执行 SHOW CREATE TABLE，确认改写针对的是当前分区表达式。
2. 用同一组参数执行 EXPLAIN，记录 partitions 列是否减少。
3. 把时间窗口扩大一档，确认命中的分区数量随边界变化，而不是固定扫描全表。
4. 如果仍命中全部分区，再检查 OR、类型转换和分区设计，不要继续堆叠函数。

如果业务查询经常跨越大部分历史分区，裁剪收益自然有限；这时应该把分区当作生命周期与维护边界，再用合适索引解决分区内部的访问路径。

常见问题

看到 partitions 列有多个分区，是否就说明裁剪失败？

不一定。日期范围跨越多个边界时，访问这些分区是必要的。只有在范围很窄却命中全部分区，或改写前后命中集合完全不变时，才值得继续排查。

为什么使用 BETWEEN 仍然看不到明显收益？

可能是范围覆盖过宽，也可能是上界包含了下一边界的时间值。对 DATETIME 更推荐半开区间，并以 EXPLAIN 的分区集合判断结果。

分区裁剪和索引优化需要二选一吗？

不需要。裁剪先决定访问哪些分区，索引再决定每个分区内部如何找行；生产查询通常需要同时检查两层执行计划。