MySQL 分区表让时间范围查询命中分区的实现方法

我第一次给订单明细表加时间分区时，直觉是“只要按月分区，按月查就会变快”。实际更容易踩坑的地方是分区键和 WHERE 条件没有对齐：查询虽然写了日期范围，优化器却无法排除无关分区。判断这件事只看三个指标就够了：partitions 是否缩小、key 是否走到预期索引、rows 是否仍然覆盖过大的数据范围。

官方资料：https://dev.mysql.com/doc/refman/8.4/en/partitioning-pruning.html

分区键与时间范围要先对齐

分区裁剪的核心很朴素：如果某个分区不可能包含结果，优化器就不扫描它。时间明细通常适合用 RANGE COLUMNS，因为分区边界直接使用 DATETIME，读写方不必先把时间转换成年份或月份整数。

CREATE TABLE order_event (
    id BIGINT NOT NULL,
    event_time DATETIME NOT NULL,
    user_id BIGINT NOT NULL,
    event_type VARCHAR(32) NOT NULL,
    PRIMARY KEY (id, event_time)
)
PARTITION BY RANGE COLUMNS (event_time) (
    PARTITION p202601 VALUES LESS THAN ('2026-02-01 00:00:00'),
    PARTITION p202602 VALUES LESS THAN ('2026-03-01 00:00:00'),
    PARTITION p202603 VALUES LESS THAN ('2026-04-01 00:00:00'),
    PARTITION pmax VALUES LESS THAN (MAXVALUE)
);

这里的 VALUES LESS THAN 是上界，不是闭区间。于是 2026 年 2 月的记录属于 p202602，不会同时落进两个分区。主键示例把分区列放进键中，是为了满足分区表唯一键的设计约束；生产表还要结合真实主键、写入方式和索引需求决定。

用半开区间让谓词直接落到分区键

查询时我更愿意固定成下面这种写法：起点用 >=，终点用 。它既能覆盖完整月份，也能避免把一天的最后一秒写死。

SELECT id, user_id, event_type, event_time
FROM order_event
WHERE event_time >= '2026-02-01 00:00:00'
  AND event_time 

相反，下面的条件把列包进了 DATE()。它表达的业务意思没有错，但分区裁剪能否识别会变得不稳定；当查询还需要按时间索引定位行时，也可能增加额外计算。

SELECT COUNT(*)
FROM order_event
WHERE DATE(event_time) = '2026-02-18';
-- 中文说明：列被函数包裹，改写为半开区间更容易暴露原始分区键。

对应的改写是：

SELECT COUNT(*)
FROM order_event
WHERE event_time >= '2026-02-18 00:00:00'
  AND event_time 

用 EXPLAIN PARTITIONS 复核三个关键指标

不要因为 SQL 看起来像“按月查”就默认命中了分区。把真实查询放进执行计划，重点看下面三列：

EXPLAIN PARTITIONS
SELECT id, user_id, event_type
FROM order_event
WHERE event_time >= '2026-02-01 00:00:00'
  AND event_time 

范围过宽和边界错误要分开排查

如果 partitions 几乎列出全部分区，先看两件事。第一，查询时间范围是否本来就跨了大半个生命周期；裁剪只能排除范围外的分区，不能把一个真实的大范围变成小范围。第二，谓词是否在分区列上做了函数、隐式类型转换，或使用了无法还原边界的表达式。

再检查边界数据：分区定义用的是“小于上界”，查询最好也统一成“左闭右开”。新增月份前先确认上一个 MAXVALUE 分区的处理方案，避免新数据长期堆在兜底分区里。分区裁剪解决的是扫描范围，不替代分区内索引，也不替代合理的时间条件。

相关问题

用了 BETWEEN 就一定能裁剪吗？

不一定。MySQL 对部分可化简的范围可以进行裁剪，但业务代码更推荐显式写半开区间，并用执行计划确认实际分区集合。

只按 event_type 查询为什么没有明显收益？

因为当前分区键是 event_time。没有时间边界时，优化器无法仅凭 event_type 排除时间分区；应先判断业务过滤条件是否真的适合按时间组织。

分区命中了，为什么 rows 仍然很大？

命中分区只说明缩小了物理范围，分区内仍可能缺少合适索引，或者时间范围本身很宽。继续结合 key、rows 和数据分布判断，不要只看 partitions 一列。