分区裁剪执行计划怎么配置或排查
来源: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 ,边界清楚且容易覆盖整段时间。 EXPLAIN的partitions显示候选分区;还要结合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 和毫秒边界带来的漏数问题。

日期条件怎样写才容易产生裁剪
在这个模型上,推荐把时间范围写在原始分区列上:
-- 直接过滤分区键,查询一个完整月份
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、过滤条件 | 裁剪生效不等于分区内查询高效 |

裁剪不出现时按这份清单排查
- 先看定义:用
SHOW CREATE TABLE orders确认真正的分区表达式和边界,别只看应用里的建表脚本。 - 再看谓词:确认过滤列就是分区键,参数类型和列类型一致,避免隐式转换让条件难以推导。
- 缩小范围:范围覆盖大多数分区时,继续裁剪的收益有限;跨年查询本来就可能命中很多分区。
- 对照计划:分别执行带条件和不带条件的
EXPLAIN,比较partitions与rows,不要只凭执行时间猜测。 - 检查统计:裁剪后的分区内仍可能因为索引设计、数据分布或统计估算不合适而慢;这时处理的是分区内访问路径。
-- 确认线上表的分区定义,而不是猜测分区名
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 只有一个,查询就一定快吗?
答:不一定。它只说明扫描范围缩小,还要看分区内的 type、key、rows 以及返回数据量。
-
368 收藏
-
449 收藏
-
486 收藏
-
111 收藏
-
419 收藏
-
169 收藏
-
181 收藏
-
338 收藏
-
387 收藏
-
406 收藏
-
195 收藏
-
156 收藏
-
412 收藏
-
172 收藏
-
311 收藏
-
352 收藏
-
431 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 485次学习