MySQL 优化器直方图数据分布变化后怎样更新列统计信息怎样在批处理代码中减少额外分配

MySQL 列值分布明显变化后，可以用 ANALYZE TABLE ... UPDATE HISTOGRAM ON ... 重新生成指定列的直方图。直方图为优化器提供分布信息，不是索引，也不直接减少应用程序对象分配。批处理代码要减少额外分配，应从合并同表任务、缩小统计查询字段和复用结果容器着手。

例如批量导入改变了订单状态的占比，旧统计可能不再代表当前数据。先确认需要更新的列和业务查询，再决定刷新方式；不能把“统计已更新”直接等同于“查询一定更快”。以下以MySQL 8.4官方语义讲解，示例未执行，不附伪造性能数字。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/optimizer-statistics.html

把索引统计和列直方图区分开

索引统计与列直方图都是优化器输入，但不是一个对象。普通 ANALYZE TABLE 与显式 UPDATE HISTOGRAM 应区别理解；不要默认所有已有直方图都会跟着任意数据写入实时变化。

先选数据倾斜明显、参与实际过滤条件的列。单列直方图也不能完整表达多列之间的相关性。增加桶数或为很多列建立统计，不会自动解决不合适的索引和查询表达式。

针对分布变化的列更新统计

-- 假设练习库已有 orders 表和非唯一列 status；按实际表名替换。
-- 一条语句可更新同表多个合适的列；64只是示例桶数。
ANALYZE TABLE orders UPDATE HISTOGRAM ON status WITH 64 BUCKETS;

命令以表和列为管理单位，会替换指定列已有直方图，不修改业务行。桶数64是示例选择，不是通用推荐。列的不同值数量和分布会影响生成形式；采样也可能未覆盖某些重要取值。

在批量导入完成后按受影响列提交一次任务，比每插入一批业务行都重新生成统计更容易控制开销。维护语句仍可能消耗读取资源并受到锁或权限影响，应放入合适的维护窗口，而不是混进每条业务请求。

只查询需要的统计字段

-- 只读取诊断所需标量，避免客户端反复解析完整桶数组。
SELECT COLUMN_NAME,
       JSON_UNQUOTE(JSON_EXTRACT(HISTOGRAM,'$."last-updated"')) AS updated_utc,
       JSON_EXTRACT(HISTOGRAM,'$."sampling-rate"') AS sampling_rate,
       JSON_UNQUOTE(JSON_EXTRACT(HISTOGRAM,'$."histogram-type"')) AS histogram_type
FROM information_schema.COLUMN_STATISTICS
WHERE SCHEMA_NAME=DATABASE()
  AND TABLE_NAME='orders'
  AND COLUMN_NAME='status';

last-updated 对应统计生成的UTC时间，sampling-rate 表示采样比例，histogram-type 表示直方图类型。这些字段可以帮助记录维护状态，但不能作为查询收益的替代指标。

客户端若仅需要时间和类型，就不要 SELECT 完整 HISTOGRAM 后为每行创建通用JSON对象、数组和字符串副本。上面的写法缩小返回载荷及客户端解析需求，不承诺服务器执行零分配，也不保证所有驱动都以相同方式表示JSON标量。

批处理合并任务并复用容器

批处理可以按“库名、表名”聚合受影响列，去掉重复列，再为同表生成一条 UPDATE HISTOGRAM。该语法一次只指定一张表，不能把普通 ANALYZE TABLE 的多表形式机械搬过来。

任务表应保存稳定的表列标识，而不是为同一个数据变化重复构造完整SQL和整份统计JSON。结果消费可以逐条处理，把少量标量写入已有的任务记录；若使用可复用切片或对象，须保证上一轮消费者已结束，避免复用导致结果被覆盖。

库、表、列是SQL标识符，通常不能用普通值占位符代替。只能从受控元数据白名单选择并正确引用，不能直接拼用户输入。批次合并减少的是重复工作与对象创建机会，实际分配变化仍依赖语言和驱动，不应凭SQL推断具体字节数。

处理版本与失败边界

-- MySQL 8.4支持此选择；其他版本应依据对应手册决定是否使用。
ANALYZE TABLE orders UPDATE HISTOGRAM ON status WITH 64 BUCKETS AUTO UPDATE;
-- 启用后，对此表执行ANALYZE TABLE也会更新相应直方图。
ANALYZE TABLE orders;

这里的AUTO UPDATE并不是应用侧“每次写入立即重建”的承诺。若部署并非MySQL 8.4，应查对应版本语法；不能只凭数据库名称相同就发送这个选项。

多列管理可能只对其中部分列成功并返回其他列的诊断消息。批处理必须读取返回的 Msg_type、Msg_text 等维护结果，不能仅凭连接未报错就把所有列标为完成。失败应保留原表列和实际原因，避免无限重试同一条不支持的列定义。

统计管理有类型和对象限制，例如不能据此为JSON列、临时表或单列唯一索引覆盖的列任意生成直方图。维护前要清楚具体对象；读统计为空时，也应区别未建立统计、表列筛选错误与访问权限。

直方图会让查询必然走索引吗？

不会。它影响选择性估计，最终访问路径还受查询结构、索引和成本判断影响。

普通ANALYZE TABLE会更新直方图吗？

需要结合版本与自动更新选项，不能把两类统计维护完全等同。8.4支持按上面的选项将直方图纳入相应更新行为。

减少客户端分配等于优化器内存减少吗？

不是。应用结果解析与服务器统计生成是两个边界，应该分别归因。

参考：https://dev.mysql.com/doc/refman/8.4/en/optimizer-statistics.html；管理语法：https://dev.mysql.com/doc/refman/8.4/en/analyze-table.html。