登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  MySQL

分区裁剪执行计划怎么配置或排查

来源:17golang原创

时间:2026-09-13 12:34:26 329浏览 收藏

MySQL 的分区裁剪不是一个需要单独打开的开关。它能否生效,取决于优化器能不能从 WHERE 条件推导出分区键的可能取值,并据此排除不可能命中的分区。按日期做 RANGE 分区时,最稳妥的写法是直接对分区键使用半开区间,再用 EXPLAIN 查看 partitions 列。

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

要点速览
  • 分区裁剪依赖分区表达式与谓词之间的可推导关系,不等于普通索引命中。
  • 日期查询优先写成 >= 起点 AND ,边界清楚且容易覆盖整段时间。
  • EXPLAINpartitions 显示候选分区;还要结合 rows 和访问类型判断收益。

先把分区键和查询条件对齐

下面用按月保存订单的表说明。表按 order_date 做范围分区,查询也直接限制这列。分区名只是示意,生产环境应按真实业务的保留周期持续维护边界。

-- 分区表达式直接使用日期列,便于优化器推导月份范围
CREATE TABLE orders (
    id BIGINT NOT NULL,
    order_date DATE NOT NULL,
    customer_id BIGINT NOT NULL,
    amount DECIMAL(12,2) NOT NULL,
    PRIMARY KEY (id, order_date)
) PARTITION BY RANGE COLUMNS (order_date) (
    PARTITION p202501 VALUES LESS THAN ('2025-02-01'),
    PARTITION p202502 VALUES LESS THAN ('2025-03-01'),
    PARTITION p202503 VALUES LESS THAN ('2025-04-01'),
    PARTITION pmax VALUES LESS THAN (MAXVALUE)
);

查询 2025 年 2 月时,使用 >= '2025-02-01',优化器可以把候选范围收窄到 p202502。半开区间也避免了 DATETIME 精度、月末 23:59:59 和毫秒边界带来的漏数问题。

MySQL 分区键与日期范围谓词对齐的结构示意图
图1:分区键、RANGE 边界与日期谓词对齐的操作示意图,不代表真实运行截图。

日期条件怎样写才容易产生裁剪

在这个模型上,推荐把时间范围写在原始分区列上:

-- 直接过滤分区键,查询一个完整月份
SELECT id, customer_id, amount
FROM orders
WHERE order_date >= '2025-02-01'
  AND order_date 

不要先对列做任意函数再期待优化器反推出分区,例如把 order_date 包在自定义函数或复杂表达式中。若表是按 YEAR(order_date)TO_DAYS(order_date) 等受支持的表达式分区,优化器在部分条件下可以利用对应表达式,但排查时仍应先让谓词和分区定义尽量保持同形。

还要区分“裁剪”和“索引”。裁剪先决定访问哪些分区;进入分区后,是否走主键或二级索引由另一层优化决定。只看到 partitions=p202502,并不代表一定有理想的索引访问。

用 EXPLAIN 看命中了哪些分区

先看带范围的查询:

-- 查看优化器计划,重点观察 partitions、type、key 和 rows
EXPLAIN
SELECT id, customer_id, amount
FROM orders
WHERE order_date >= '2025-02-01'
  AND order_date 

文本格式的计划中,如果 partitions 只出现 p202502,说明候选分区已经被缩小;如果列出 p202501,p202502,p202503,pmax,说明当前条件没有排除其他分区。再看 rows,它用于估算本次访问的行数,不能把它当成实际返回行数。

现象优先检查判断
只列一个或少量分区partitions 与 rows裁剪可能生效,再确认分区内访问方式
列出全部分区分区键是否出现在可推导谓词中通常是全分区候选,需继续排查条件
分区少但仍慢type、key、rows、过滤条件裁剪生效不等于分区内查询高效
MySQL EXPLAIN 的 partitions 与 rows 结果关系示意图
图2:EXPLAIN 中 partitions、访问方式和 rows 的结果示意图,不代表真实运行截图。

裁剪不出现时按这份清单排查

  1. 先看定义:SHOW CREATE TABLE orders 确认真正的分区表达式和边界,别只看应用里的建表脚本。
  2. 再看谓词:确认过滤列就是分区键,参数类型和列类型一致,避免隐式转换让条件难以推导。
  3. 缩小范围:范围覆盖大多数分区时,继续裁剪的收益有限;跨年查询本来就可能命中很多分区。
  4. 对照计划:分别执行带条件和不带条件的 EXPLAIN,比较 partitionsrows,不要只凭执行时间猜测。
  5. 检查统计:裁剪后的分区内仍可能因为索引设计、数据分布或统计估算不合适而慢;这时处理的是分区内访问路径。
-- 确认线上表的分区定义,而不是猜测分区名
SHOW CREATE TABLE orders;

-- 只在已经知道分区名、需要诊断或强制范围时显式选择
SELECT id, customer_id, amount
FROM orders PARTITION (p202502)
WHERE order_date >= '2025-02-01'
  AND order_date 

PARTITION (p202502) 是人为指定分区,叫“分区选择”,不是优化器自动完成的分区裁剪。它适合核对数据归属或已知分区的维护场景,不能代替正确的分区键设计;写错分区名还可能漏掉本应返回的数据。

常见问题:分区裁剪执行计划怎么判断

问:为什么用了分区表,EXPLAIN 还是显示全部分区?
答:先确认 WHERE 是否约束了分区表达式,是否被复杂函数、隐式转换或过宽范围包住;再核对 SHOW CREATE TABLE 的真实定义。

问:partitions 只有一个,查询就一定快吗?
答:不一定。它只说明扫描范围缩小,还要看分区内的 typekeyrows 以及返回数据量。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>