MySQL 分区表怎样确认查询命中了分区裁剪

MySQL 分区表是否真的减少了扫描范围，不能只看查询能否返回结果，最直接的观察点是 EXPLAIN 结果中的 partitions 列。它列出本次执行计划准备访问的分区名称：只出现目标分区，说明优化器已经把不可能命中的分区排除；如果列出全部分区，就不能把这次查询说成“命中了分区裁剪”。

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

先把“命中分区裁剪”定义清楚

分区裁剪的核心是排除不可能产生匹配行的分区。假设表按订单日期做 RANGE 分区，查询条件又直接限制了一个较短的日期范围，优化器就有机会推导出只需要查看相邻的几个分区。这个判断依赖分区表达式和 WHERE 条件之间的关系，而不是依赖表名里是否出现了 partition。

下面用一个教学表说明观察方法。分区名、日期范围和输出都是示例，重点是字段之间的对应关系：

CREATE TABLE orders (
    id BIGINT NOT NULL,
    created_at DATE NOT NULL,
    amount DECIMAL(12, 2) NOT NULL
)
PARTITION BY RANGE COLUMNS (created_at) (
    PARTITION p202501 VALUES LESS THAN ('2025-02-01'),
    PARTITION p202502 VALUES LESS THAN ('2025-03-01'),
    PARTITION pmax VALUES LESS THAN (MAXVALUE)
);

-- 直接按分区列限定范围，便于优化器推导候选分区。
EXPLAIN SELECT id, amount
FROM orders
WHERE created_at >= '2025-01-10'
  AND created_at 

这里的判断顺序是：先确认表由 created_at 划分，再确认查询对同一列给出了范围，最后读取计划中的分区集合。不要把“查询条件包含日期”误认为“必然发生裁剪”。

用 EXPLAIN 查看 partitions 列

直接执行上面的 EXPLAIN SELECT，在传统表格输出中找到名为 partitions 的列。可以把结果简化理解为下面三种观察状态：

示意输出中的 partitions 不是“最终实际扫描行数”，而是优化器计划里的分区访问范围。即使只命中一个分区，分区内部仍可能需要扫描很多行；反过来，命中两个分区也不一定是问题，关键是它是否排除了明显不相关的分区。

一些旧教程会写成 EXPLAIN PARTITIONS，但阅读当前 MySQL 8.4 的传统 EXPLAIN 输出时，重点仍是查看结果表中的 partitions 字段。不要因为看到字段名就把它当成索引名或分区表的元数据。

对照 WHERE 条件判断裁剪是否真的发生

最容易判断的是分区表达式与条件保持同一语义的写法。例如按日期范围分区时，直接对 created_at 使用等值、IN、>、 或适当的 BETWEEN，优化器更容易把条件转换成一组候选分区。范围越宽，候选分区越多；当候选范围覆盖全部分区时，partitions 列自然不会显示出裁剪收益。

-- 这个条件直接约束分区列，便于形成较小的候选集合。
EXPLAIN SELECT COUNT(*)
FROM orders
WHERE created_at >= '2025-01-10'
  AND created_at 

第二个例子不是看到日期相等就可以直接下结论。函数包裹、隐式类型转换、对分区列做计算，都会让“条件能否映射到分区范围”变得需要单独观察。最终仍以 EXPLAIN 返回的 partitions 集合为准，而不是凭经验断言。

常见误判与架构判断清单

• 把分区表当成自动加速器：分区裁剪只减少候选分区，分区内部的索引、统计信息和过滤仍然重要。
• 只看 SQL 不看计划：同一个业务条件在不同分区表达式、数据类型和写法下，可能得到不同的分区集合。
• 把跨两个分区当成失败：范围查询跨越边界很正常，只要不相关分区被排除，仍然发生了裁剪。
• 看到 NULL 就直接说“没有裁剪”：先确认目标是分区表，并区分非分区表、计划输出格式和当前查询类型。

可以用下面的清单收尾：表是否确实分区；分区表达式是什么；WHERE 是否直接约束该表达式；partitions 是否只列出必要分区；分区内部的 rows、key 和 filtered 是否仍需优化。这个观察链条比单独背诵“分区能加速查询”更可靠。

常见问题

partitions 列只显示一个分区，就代表查询一定很快吗？

不代表。它只说明计划把访问范围缩小到了一个分区，分区内部仍可能有大量行、缺少合适索引或需要复杂过滤。

查询跨越两个分区，是不是说明分区裁剪失败？

不是。只要其他不可能命中的分区没有出现在 partitions 列中，跨越多个目标分区仍然属于有效裁剪。

为什么不能只看 WHERE 里有没有分区列？

因为函数包裹、隐式转换和范围宽度都会影响优化器能否推导出具体分区集合，最终应回到 EXPLAIN 的 partitions 列确认。