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

MySQL 直方图统计信息什么时候需要手动更新

来源:17golang原创

时间:2026-10-05 12:34:34 306浏览 收藏

MySQL 直方图需要手动更新的典型时机,是列值分布已经明显变化,而现有统计仍在影响选择率估算:例如大批量导入或删除后、冷热数据比例反转后、恢复或迁移到新数据集后,以及 EXPLAIN 中估算行数与实际情况持续偏离时。MySQL 8.0 的直方图依赖手动维护;MySQL 8.4 虽然增加了 AUTO UPDATE,但未显式启用时仍以 MANUAL UPDATE 为默认模式。

MySQL 8.4 官方文档:https://dev.mysql.com/doc/refman/8.4/en/analyze-table.html

我第一次维护直方图时,犯过一个很常见的错误:以为定期执行普通的 ANALYZE TABLE 就会把直方图一起刷新。实际上,不带 HISTOGRAM 子句的语句做的是键分布分析,已有直方图不受影响。这个区别直接决定了“为什么表刚分析过,计划估算还是老样子”。

先分清直方图解决的是什么问题

直方图保存列值分布的统计摘要,优化器可以用它估算与常量比较时的过滤比例。等值、不等值、范围、BETWEEN、IN、IS NULL 等谓词都可能从中受益。它最适合没有索引、但值分布明显倾斜的过滤列。

例如订单表的 status 列中,绝大部分数据是“已完成”,只有极少部分是“待人工处理”。如果优化器只按均匀分布猜测,不同状态的行数估算可能相差很大。直方图让它看到这种倾斜,但不会替代索引,也不会保存每一行的值。

MySQL 列值分布、直方图桶、COLUMN_STATISTICS 与优化器选择率估算的静态关系图
图1:列值分布经直方图桶进入 COLUMN_STATISTICS,优化器用这些统计信息估算选择率;这是静态关系说明图,不是数据库运行截图。

这也解释了为什么“查询变慢”不能直接推导出“直方图该更新”。如果目标列已经有适用索引,范围优化器或索引探测能给出更好的估算,优化器可能优先使用这些信息。先确认直方图确实参与了当前问题,再决定维护动作。

先查当前直方图处于什么状态

我通常先从 INFORMATION_SCHEMA.COLUMN_STATISTICS 读取四个字段:最后更新时间、自动更新状态、桶数和采样比例。它们能回答“有无直方图”“是不是手动模式”“统计有多旧”,但不能单独证明统计已经失真。

-- 查看目标列的直方图元数据,不直接读取数据字典底表
SELECT
    SCHEMA_NAME,
    TABLE_NAME,
    COLUMN_NAME,
    HISTOGRAM->>'$."last-updated"' AS last_updated,
    HISTOGRAM->>'$."auto-update"' AS auto_update,
    HISTOGRAM->>'$."sampling-rate"' AS sampling_rate,
    HISTOGRAM->>'$."histogram-type"' AS histogram_type,
    HISTOGRAM->>'$."number-of-buckets-specified"' AS bucket_count
FROM INFORMATION_SCHEMA.COLUMN_STATISTICS
WHERE SCHEMA_NAME = 'shop'
  AND TABLE_NAME = 'orders'
  AND COLUMN_NAME = 'status';

last-updated 是直方图生成时间,sampling-rate 表示生成时读取的数据比例,histogram-type 可能是单值型或等高型。更新时间很旧只是提醒,不是定时重建的充分条件;真正要比对的是这段时间内分布有没有改变,以及执行计划估算有没有偏离。

这五种情况值得手动更新

1. 批量导入、删除或归档改变了值分布

日常少量写入通常不值得每次都重建直方图。更重要的是分布形状是否改变:一次 ETL 导入大量新地区数据、历史归档删除大部分旧状态、活动期间某类订单突然占据多数,都可能让旧桶失去代表性。

2. 业务含义没变,但冷热比例反转

有些列的枚举值没有新增,比例却完全变了。比如原先 pending 只占极小部分,流程调整后变成主要状态。仅看不同值数量会觉得“没有变化”,但优化器最关心的选择率已经变了。

3. EXPLAIN 的估算与实际持续不符

一次执行波动不必立刻更新。更有价值的信号是:同一类谓词持续出现明显估算偏差,并且目标列没有更合适的索引统计可用。此时重建直方图,再以同一 SQL 和同一参数范围比较计划,是成本较低的验证方式。

4. 数据恢复、蓝绿切换或环境迁移后

结构相同不代表数据分布相同。把生产结构恢复到缩小版测试数据、按租户迁移部分数据、切换到刚完成全量同步的新实例后,旧直方图可能与新实例的真实分布不匹配。迁移清单中应把直方图状态单独列出来,不能只检查索引是否存在。

5. 要改变桶数,或排除过期统计的影响

MySQL 允许 1 到 1024 个桶,省略 WITH N BUCKETS 时默认使用 100。桶数不是越大越好;分布复杂但桶数太少时可能粗糙,桶数过多则增加统计生成和存储成本。调整桶数本身就需要重新生成直方图。

现场信号是否优先手动更新先确认什么
每天少量均匀写入通常不需要计划和估算是否稳定
批量导入或删除后比例改变是目标列分布是否明显偏移
查询慢但估算基本合理不一定索引、I/O、锁等待和 SQL 写法
估算行数持续严重偏离值得验证直方图是否适用于该谓词
MySQL 8.4 已启用 AUTO UPDATE通常减少手工频次自动更新是否发生、是否需要立即同步刷新
迁移后数据集与原实例不同是直方图是否随迁移正确重建

MySQL 8.0 与 8.4 的更新方式差在哪里

我更愿意把这看成一项维护策略变化,而不是一句“8.4 会自动更新”。MySQL 8.4 新增了直方图自动更新选项,但它需要显式启用;不写 AUTO UPDATE 时,MANUAL UPDATE 仍是默认。

启用自动更新后,针对该表执行 ANALYZE TABLE 时会使用之前指定的桶数更新直方图;InnoDB 后台线程重新计算持久统计信息时,也会更新启用了自动模式的直方图。这并不等于每次行变更都立即重建。

MySQL 8.0 与 8.4 直方图 MANUAL UPDATE 和 AUTO UPDATE 的静态依赖关系图
图2:MySQL 8.4 增加 AUTO UPDATE,但 MANUAL UPDATE 仍是默认;自动更新与 ANALYZE TABLE、持久统计重算存在明确关系。

这里最容易混淆的是“表数据变化 10%”这个数字。它描述的是启用 InnoDB 持久统计自动重算时的一项触发条件,不是所有直方图都必须按 10% 变化量更新的通用规则。手动直方图仍应依据分布和计划证据判断。

手动更新的最小写法

确认需要更新后,可以只处理真正参与估算的列,不要把整张表所有列都加入直方图。下面把 status 和 region_code 分别设置为 128 个桶:

-- 只更新两个有倾斜分布、且常用于常量过滤的列
ANALYZE TABLE shop.orders
UPDATE HISTOGRAM ON status, region_code
WITH 128 BUCKETS
MANUAL UPDATE;

该语句会替换目标列已有的直方图,其他列不受影响。执行需要对表具备 SELECT 和 INSERT 权限。官方文档还说明,分析期间 InnoDB 和 MyISAM 表会持有读锁,因此生产环境应放在低峰窗口,并控制一次处理的列和表数量。

另外,普通写法与直方图写法不能混为一谈:

-- 只分析键分布,已有直方图保持不变
ANALYZE TABLE shop.orders;

-- 明确重新生成 status 列的直方图
ANALYZE TABLE shop.orders
UPDATE HISTOGRAM ON status
WITH 100 BUCKETS;

MySQL 8.4 什么时候适合启用 AUTO UPDATE

如果表本来就有稳定的统计维护节奏、数据分布会持续变化,而且团队不希望维护额外的直方图刷新任务,自动模式很合适。启用语法如下:

-- MySQL 8.4:为目标列启用自动更新,并固定沿用 128 个桶
ANALYZE TABLE shop.orders
UPDATE HISTOGRAM ON status
WITH 128 BUCKETS
AUTO UPDATE;

我不会因此删除所有人工复查。以下情况仍可能需要手动触发:刚完成批量装载,需要在业务放量前立即获得新统计;自动重算尚未发生,但计划已经明显偏离;准备改变桶数;或者正在排查自动统计是否能解释计划变化。

相反,如果表非常大、维护窗口严格、数据分布长期稳定,或者团队需要精确控制统计变更时点,继续使用手动模式更容易管理。自动和手动不是优劣关系,关键是能否解释“什么时候改变了优化器输入”。

更新后怎么确认真的有帮助

不要只比较一次执行耗时。缓存、并发和 I/O 都可能让耗时产生噪声。更可靠的复查顺序是:保留更新前的执行计划,更新后用同一 SQL、同一参数范围重新查看估算,再观察访问路径、连接顺序和过滤比例是否更合理。

-- 更新前后都用同一条查询查看 JSON 执行计划,便于比较估算
EXPLAIN FORMAT=JSON
SELECT order_id, customer_id
FROM shop.orders
WHERE status = 'pending'
  AND region_code IN ('EAST', 'NORTH');

-- 如果直方图持续造成不稳定估算,可删除目标列直方图后再对照
ANALYZE TABLE shop.orders
DROP HISTOGRAM ON status, region_code;

删除直方图不是失败,而是合法的回退方式。官方文档也建议:如果怀疑过期直方图没有改善执行,可以先重新生成并再次运行查询;若仍无收益,则可以删除直方图。不要为了“已经建了统计”而强行保留。

迁移或升级时的检查清单

  • 确认目标实例版本,MySQL 8.0 不要使用 8.4 才支持的 AUTO UPDATE 语法;
  • 从 COLUMN_STATISTICS 记录目标列、更新时间、桶数、采样比例和自动更新状态;
  • 保留关键 SQL 的更新前执行计划,不只保存耗时;
  • 核对恢复、同步或归档是否改变了列值比例;
  • 只为有明确估算价值的列建立直方图;
  • 在低峰窗口执行,确认所需权限和复制策略;
  • 更新后对比估算、访问路径和业务延迟;
  • 收益不稳定时调整桶数,或删除直方图回退。

相关问题

普通 ANALYZE TABLE 会自动刷新直方图吗?

手动模式下不会。普通语句分析键分布,已有直方图保持不变。MySQL 8.4 中只有目标直方图显式启用 AUTO UPDATE 后,相关分析和持久统计重算才会按规则带动更新。

直方图多久更新一次合适?

没有适用于所有表的固定周期。优先关注数据分布变化和估算偏差;稳定表可以长期不动,批量装载和比例反转后的表应尽快评估。

桶数应该直接设为 1024 吗?

不建议默认拉满。先从默认 100 或较小调整值开始,根据不同值数量、分布复杂度、采样和执行计划效果决定。桶更多不保证计划更好。

有索引的列还需要直方图吗?

不一定。官方文档指出,直方图主要对非索引列有用;索引探测可能提供更好的估算。如果范围优化器已经适用,优化器会优先使用它的行数估算。

对我来说,最实用的判断不是“距离上次更新多久”,而是“数据分布是否已经换了一种形状,以及优化器是否还在相信旧形状”。把这两个问题回答清楚,手动更新就从例行仪式变成了可解释的维护动作。

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