MySQL 分区表怎么确认裁剪生效：EXPLAIN 分区信息、范围条件与维护检查

线上订单表按月份做了 RANGE 分区，慢查询却仍然像是在扫整张表。先别急着把分区数继续加大：真正要确认的是，查询条件能不能让优化器排除无关分区。对 MySQL 来说，EXPLAIN 输出里的 partitions 字段是第一处证据；它列出的分区越少，才越接近“裁剪生效”，最终还要结合实际扫描行数和业务延迟验收。

先用一个按月订单表复现问题

下面的示例只关注检查方法。假设表按 created_at 做月份范围分区，历史分区保留到 p2026_06，最后用一个兜底分区接住更晚的数据：

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 p2026_04 VALUES LESS THAN ('2026-05-01'),
  PARTITION p2026_05 VALUES LESS THAN ('2026-06-01'),
  PARTITION p2026_06 VALUES LESS THAN ('2026-07-01'),
  PARTITION pmax VALUES LESS THAN (MAXVALUE)
);

这里的主键写法是为了满足分区键必须出现在唯一键中的约束示意。真实表结构如果已有自增主键，先检查唯一键、外键和 ORM 生成 SQL，再决定是否能直接改成分区表。

EXPLAIN 里的 partitions 字段怎么看

查询一个完整月份时，优先使用半开区间。它能避开 DATETIME 末尾的精度问题，也让边界更容易与分区定义对应：

EXPLAIN
SELECT id, user_id, amount
FROM orders
WHERE created_at >= '2026-05-01 00:00:00'
  AND created_at 

观察结果时先找 partitions 列。理想情况下它只列出 p2026_05；如果出现 p2026_04,p2026_05,p2026_06,pmax，说明当前条件没有把范围有效地缩小到目标分区。这个字段是执行计划阶段的判断，不等于已经读取了多少行，所以还要继续看 rows、过滤比例和实际耗时。

用 EXPLAIN ANALYZE 做第二次核对

在支持该语法的版本和可接受的测试环境里，可以用 EXPLAIN ANALYZE 观察实际执行行数。生产环境不要直接对高峰期的大查询做实验，先复制相同数据分布或在低峰灰度。

EXPLAIN ANALYZE
SELECT COUNT(*)
FROM orders
WHERE created_at >= '2026-05-01'
  AND created_at 

验收时把计划证据和业务证据放在一起：partitions 是否只有目标分区、实际读取行数是否符合该月数据量、同一查询的响应时间是否下降。只看到第一项变好，不足以证明整体方案有效。

哪些写法容易让裁剪判断失真

尤其要注意时区。应用把本地时间转换成 UTC 后再写库，如果分区边界却按本地月份定义，查询看起来是“五月”，实际范围可能跨越两个分区。先在日志里打印绑定后的完整时间范围，再看执行计划，别只看 ORM 里的占位符。

分区裁剪确认后，还要做三项维护检查

确认分区边界和数据分布

可以从 information_schema.PARTITIONS 读取分区名、边界描述和近似行数，检查是否存在空分区、数据落入兜底分区或边界没有提前准备。统计值用于趋势判断，不要把它当成精确行数。

SELECT PARTITION_NAME, PARTITION_DESCRIPTION, TABLE_ROWS
FROM information_schema.PARTITIONS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'orders'
ORDER BY PARTITION_ORDINAL_POSITION;

统计信息变化后重新观察计划

大量导入、删除或分区调整后，优化器看到的统计信息可能已经不适合当前数据分布。需要在低峰期评估 ANALYZE TABLE orders 的影响，再重新执行同一条 EXPLAIN。不要把“重新统计”当成裁剪失效的万能修复。

给未来月份留出可操作的边界

按月滚动的表要有明确的加分区、归档和兜底处理。执行 ALTER TABLE 前先确认锁影响、备份策略和副本延迟；删除历史分区属于高风险运维动作，必须先核对保留期限和恢复方案。

常见问题

partitions 只显示一个分区，就一定更快吗？

不一定。它只说明候选分区范围变小；单个分区仍可能数据量巨大，也可能因为缺少合适索引而扫描大量行。继续看实际行数、索引访问方式和端到端耗时。

为什么查询只查一天，却列出两个分区？

常见原因是时间边界、时区转换或分区表达式与查询表达式不一致。把最终绑定参数、分区定义和 EXPLAIN 输出放在一起对照，通常比猜优化器行为更快。

分区表还需要普通索引吗？

需要。分区裁剪与索引解决的是两个层次的问题：前者减少候选分区，后者减少分区内需要访问的记录。按真实过滤、排序和连接条件设计索引。

一份可复用的验收清单

• 记录分区键、分区类型、每个边界和兜底分区的用途。
• 用业务真实的时间范围执行 EXPLAIN，确认 partitions 与预期一致。
• 对比 rows、实际读取行数、响应时间和副本延迟。
• 检查函数包裹、隐式转换、跨时区和跨月份条件。
• 把新增分区、统计信息、归档及回滚动作写进值班手册。

分区表的价值不在于“表名后面多了几个分区”，而在于查询条件、数据边界和维护动作能互相对上。先用执行计划证明裁剪范围，再用实际运行数据证明收益，排查会稳很多。