MySQL 分区表为什么没有变快：按时间查询的分区裁剪验证方法

很多人建好分区表之后，按时间维度查订单的速度还是没提上来，这类场景在实际业务里并不少见。问题通常不出在“有没有建分区”本身，而在于查询条件能不能让优化器提前过滤掉完全无关的分区：如果时间列被函数包裹、触发了隐式类型转换，或者条件根本没落在分区键上，分区表最后只会剩下一个结构更复杂的存储壳子，完全起不到裁剪提速的作用。

判断分区是不是真的生效提速，先看执行计划里实际访问了哪些分区，再用同一条查询对比真实扫描行数和耗时，别拿“表已经按月分区”这种结论代替实打实的验证。

先从慢查询现场确认：分区到底裁掉了什么

假设有一张按月分区的订单表，分区键是 created_at：

CREATE TABLE orders (
  id BIGINT NOT NULL,
  user_id BIGINT NOT NULL,
  created_at DATETIME NOT NULL,
  amount DECIMAL(12, 2) NOT NULL,
  PRIMARY KEY (id, created_at),
  KEY idx_user_created (user_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)
);

先不要急着改索引。把业务中的原始 SQL 带入执行计划，观察 partitions 列：

EXPLAIN PARTITIONS
SELECT id, user_id, amount
FROM orders
WHERE created_at >= '2026-02-10 00:00:00'
  AND created_at 

理想结果是只出现 p202602。如果计划列出 p202601,p202602,p202603,pmax，说明这条条件没有完成有效裁剪，接下来应先排查表达式和边界，而不是简单增加分区。

最小可复现条件：让时间范围保持可裁剪

分区裁剪的核心逻辑，是从查询条件里推导出分区键对应的数值范围。下面几种写法看起来都是“查询某一天的数据”，实际跑起来的执行效果很可能天差地别。

推荐使用左闭右开区间

WHERE created_at >= '2026-02-10 00:00:00'
  AND created_at 

左闭右开既不会漏掉当天最后一秒的微秒数据，也方便优化器直接推导范围。传参时让应用层绑定 DATETIME 或明确格式的字符串，避免把日期拼成不稳定的表达式。

函数包裹分区键时先做对照实验

-- 需要重点对照的写法
WHERE DATE(created_at) = '2026-02-10'

-- 改成范围条件
WHERE created_at >= '2026-02-10 00:00:00'
  AND created_at 

DATE(created_at) 让条件先对每行计算日期，优化器未必能把它还原成分区范围。改写后再次执行 EXPLAIN PARTITIONS，只要访问分区和估算行数明显下降，方向就比“继续加索引”更可靠。

隐式转换和非分区键条件不能混为一谈

WHERE created_at = 20260210 这类混合类型条件需要特别谨慎；同时，如果主要条件是 user_id，而分区键是 created_at，分区只能按时间排除数据，不能代替 user_id 索引。先看查询的真实过滤顺序，再决定是否保留联合索引。

执行计划里应该核对的四个字段

同一条SQL至少要做两次对照测试：原始写法跑一次，改写后的范围写法再跑一次。重点核对以下信息：

• partitions：实际计划涉及哪些分区，是否从全量变成单月或少数月份。
• type 与 key：裁剪后是否仍能使用合适索引，分区裁剪和索引访问是两层能力。
• rows：估算需要检查的行数是否下降；它不是实际行数，但适合做同口径比较。
• Extra：留意过滤、临时表和排序等额外成本，避免只看到分区数量少就宣布优化成功。

如果版本支持，继续用 EXPLAIN ANALYZE 对比实际耗时和实际行数。但要记住它会真的执行语句，线上大表应先用只读副本或低风险窗口验证，并给查询加上业务侧的时间上限。

分区没有带来收益时，先判断是不是设计问题

如果确认分区裁剪已经生效，但查询速度还是很慢，原因大概率是单个分区的数据量依旧太大、需要回表的字段太多、排序操作落到了磁盘上，或者查询本身就跨越了太多分区。分区本身只是帮你缩小了搜索的数据范围，没法替代合理的索引设计和冷数据归档策略。

反过来，如果大多数查询都按 user_id 或订单状态过滤，很少按时间限制，按时间分区就未必是合适的第一层设计。可以用慢日志和近一段时间的真实查询样本统计跨分区比例，确认维护成本是否值得。

常见问题与排查顺序

为什么分区数量少了，耗时却没有明显下降？

可能瓶颈在单个分区内部的索引、回表或排序，也可能结果集本来就很大。继续看 rows、实际返回行数和执行阶段耗时，不要只比较 partitions 字符串。

能不能把查询都改成分区键条件？

不能为了实现分区裁剪，硬加没有实际业务语义的时间条件。所有用到的时间范围都得符合真实的业务约束，不然很容易出现查不到数据的漏数问题。正确的做法是先把查询语义确认清楚，再让分区键自然参与到过滤逻辑里。

什么时候应该考虑取消分区？

如果日常的查询模式几乎用不到分区键、分区数量太多带来了没必要的维护成本，或者单分区的大小和索引设计本身就足够支撑当前业务需求，完全可以在测试环境对比普通表、归档表和分区表的表现差异，再安排后续的迁移调整。

把验证结果留在变更记录里

一次完整可靠的分区优化操作，至少要记录下原始SQL、改写后的SQL、执行计划输出的分区访问列表、估算行数和实际扫描行数、测试覆盖的数据范围以及对应的回滚方案。这样后续数据量继续上涨、跨的月份越来越多的时候，团队才能快速判断出问题是查询条件写法退化、统计信息不准，还是当前的分区设计已经摸到了能力边界。