MySQL 直方图统计怎么判断该不该建:ANALYZE TABLE、桶数量与执行计划复核
来源:17golang原创
时间:2026-08-30 01:55:27 420浏览 收藏
线上订单列表突然走了一个不合适的连接顺序,第一眼看索引都在,真正可疑的是 orders.status 的数据分布:已完成订单占绝大多数,待支付却只占很小一部分。遇到这种“列有索引但估算不准”的场景,MySQL 直方图值得先做一次小范围验证,而不是直接堆新索引。
直方图适合帮助优化器修正非均匀列的选择率估算;它不能替代索引,也不应在没有执行计划对照时盲目创建。先用
ANALYZE TABLE ... UPDATE HISTOGRAM建立统计,再用COLUMN_STATISTICS和EXPLAIN检查是否真的改变了判断。
要点速览
- 优先考虑过滤列值分布明显倾斜、但暂时不适合新增索引的查询。
WITH N BUCKETS的桶数范围是 1 到 1024,省略时默认 100。COLUMN_STATISTICS可核对直方图是否存在以及是否发生采样。- 最终验收看估算行数、访问路径和实际业务查询是否一起变好。
先判断:问题是索引缺失,还是选择率估算偏了
直方图记录的是列值分布,优化器可以用它估算常量比较条件的过滤效果。它更适合处理 status = 'PENDING'、amount BETWEEN 100 AND 300 这类谓词,而不是把一条本来应该走索引的查询“变成”索引查询。
可以先保留一条真实查询,例如:
EXPLAIN
SELECT order_id, user_id
FROM orders
WHERE status = 'PENDING'
AND created_at >= '2026-08-01';
重点看 rows 与实际返回行数的差距。如果差距主要来自 status 的倾斜分布,再进入直方图实验;如果查询缺少必要的复合索引,先补索引设计更直接。
用 ANALYZE TABLE 建一份可撤销的直方图
对本例先只处理 status,避免一次改变多个变量:
ANALYZE TABLE orders
UPDATE HISTOGRAM ON status WITH 16 BUCKETS;
MySQL 8.4 的 WITH N BUCKETS 接受 1 到 1024 的整数;不写时默认 100。16 桶足以作为低成本对照,桶数不是越大越好,表很大或分布变化频繁时还要关注生成统计的内存和采样。

这条路径的关键不是“执行了一条 ANALYZE 命令”,而是 orders 的 status 分布被整理成优化器可读取的统计信息。建完后马上核对数据字典视图:
SELECT TABLE_NAME, COLUMN_NAME, HISTOGRAM
FROM INFORMATION_SCHEMA.COLUMN_STATISTICS
WHERE TABLE_SCHEMA = DATABASE()
AND TABLE_NAME = 'orders'
AND COLUMN_NAME = 'status';
用 COLUMN_STATISTICS 检查桶数与采样状态
INFORMATION_SCHEMA.COLUMN_STATISTICS 是查看直方图的入口。结果中的 JSON 会包含桶信息;如果生成统计时受 histogram_generation_max_mem_size 影响而采样,还能从 sampling-rate 判断是否读取了全表。
这里先确认三件事:行确实属于 orders.status,直方图不是另一列残留的结果,采样率没有被误读成业务成功率。采样率为 1 表示生成时读取了全部数据;小于 1 说明采用了页面级采样,复核时要把它记进变更记录。
重新跑 EXPLAIN:看估算是否更接近真实结果
回到同一条查询重新执行 EXPLAIN,把建直方图前后的 rows、访问类型和连接顺序放在一起比较:
EXPLAIN
SELECT order_id, user_id
FROM orders
WHERE status = 'PENDING'
AND created_at >= '2026-08-01';

如果 rows 更接近实际返回量,且没有引入更差的扫描或排序路径,实验才算有价值。不要只看计划文本发生变化:用同一批参数执行真实查询,观察响应时间、扫描行数和锁影响,才能决定是否保留。
桶数怎么调:从小对照开始,不要把统计当索引
16 桶是一个容易回滚的起点。若分布有很多窄峰,16 桶无法表达差异,可以再试 32 或 64 桶;每次只改桶数,并重新记录 EXPLAIN 与业务查询结果。连续增大桶数却没有改善估算,就应该停下来检查谓词、数据新鲜度和索引,而不是继续加桶。
不需要时可以删除该列直方图:
ANALYZE TABLE orders
DROP HISTOGRAM ON status;
删除后再次执行同一条 EXPLAIN,确认回到原始计划。这一步很重要:它证明实验确实由直方图造成,也给生产回滚留下了明确动作。
几个容易误判的边界
- 有索引不等于一定要建直方图:索引选择问题应先看列顺序、覆盖范围和回表成本。
- 直方图不是实时缓存:订单状态变化很快时,旧分布可能让估算再次偏离,需要按业务变更节奏更新。
- 不要混用多条实验结论:同时改索引、桶数和 SQL 写法,最后很难知道是哪一项带来了变化。
- 采样要写进验收记录:
sampling-rate小于 1 时,计划改善仍应通过真实查询复测。
相关问题
直方图能替代 status 上的索引吗?
不能。它主要修正优化器对列分布和过滤选择率的估算,索引仍负责提供访问路径。
桶数是不是越大越准确?
不一定。桶数要和分布复杂度、生成成本及计划收益一起评估,先做 16 桶对照通常更容易定位效果。
如何确认直方图已经被使用?
至少对比建立前后的 EXPLAIN,再结合 COLUMN_STATISTICS 中的列名、直方图内容和采样率复核;只看到建表语句成功还不够。
把一次直方图实验收成可回滚变更
一份合格记录至少包括目标查询、过滤列、桶数、生成时的采样率、建立前后 EXPLAIN、真实查询复测和删除语句。这样做的好处是,直方图不再是“感觉可能有用”的配置,而是一项能解释、能对照、能撤回的优化实验。
-
374 收藏
-
499 收藏
-
384 收藏
-
184 收藏
-
265 收藏
-
202 收藏
-
235 收藏
-
209 收藏
-
249 收藏
-
173 收藏
-
161 收藏
-
数据库 · MySQL | 11小时前 | MySQL · 事务 · 并发控制 · 隔离级别 · InnoDB · READ COMMITTED MySQL一致性读 当前读 快照读 REPEATABLE READ FOR UPDATE207 收藏
-
349 收藏
-
数据库 · MySQL | 12小时前 | MySQL · 索引 · 数据库 · 执行计划 · 性能排查 · 执行计划 cost_info MySQL EXPLAIN FORMAT=JSON rows_examined_per_scan 索引选择276 收藏
-
数据库 · MySQL | 12小时前 | MySQL · 事务 · C API · 批量写入 · 批量Insert mysql_info mysql_affected_rows CLIENT_FOUND_ROWS152 收藏
-
248 收藏
-
264 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 485次学习