MySQL histogram 怎样更新列分布统计而不改表结构

可以。MySQL 的 histogram 属于优化器使用的列分布统计，更新它不需要执行 ALTER TABLE，也不会新增字段或索引。针对一个列重新采集分布时，使用 ANALYZE TABLE ... UPDATE HISTOGRAM ON ... 即可；真正被改写的是数据字典中的统计信息。

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

如果目标是让优化器重新认识某个列的取值分布，优先更新 histogram；如果目标是改变表结构，才考虑 DDL。两者是不同的操作面。

先把“改表”和“改统计”分开

histogram 解决的是优化器对列分布估计不准确的问题。例如订单状态只有少数几种值，但某个状态占比突然变高，优化器可能需要新的分布信息来估算过滤条件的选择性。这个动作不会改写 CREATE TABLE 定义，也不会替查询自动创建索引。

可以把一次更新看成三层：查询条件提供需要估算的列，histogram 记录列值分布，优化器读取这份统计做基数估算。表字段、索引定义和约束仍由原来的表结构负责。

用 ANALYZE TABLE 更新指定列

最小写法是下面这样。示例中的表名和字段是虚构的，重点是语法和影响范围。

-- 只重新生成 status 列的分布统计，不改变 orders 的表结构
ANALYZE TABLE shop.orders
  UPDATE HISTOGRAM ON status;

-- 用 32 个桶描述 amount 的分布，桶数范围是 1 到 1024
ANALYZE TABLE shop.orders
  UPDATE HISTOGRAM ON amount WITH 32 BUCKETS;

没有写 WITH N BUCKETS 时，MySQL 使用默认桶数 100。桶数不是越大越好：分布复杂、数据量较大时可以增加，但也要考虑统计生成的内存和维护成本。对变化不大的列，较小的桶数通常更容易维护。

一次语句可以更新同一张表中的多个列：

-- 同一张表的两个列一起更新；没有列在这里的 histogram 不受影响
ANALYZE TABLE shop.orders
  UPDATE HISTOGRAM ON status, amount WITH 32 BUCKETS;

需要注意，带 UPDATE HISTOGRAM 的语法只允许一个表名。它更新的是列统计，不是普通的整表键分布分析。若只想刷新普通索引统计，使用不带 histogram 子句的 ANALYZE TABLE 是另一条路径。

从 COLUMN_STATISTICS 确认统计对象

更新命令返回成功消息后，可以从 INFORMATION_SCHEMA.COLUMN_STATISTICS 读取指定表和列的 histogram JSON。这个查询只读数据字典中的统计内容，不会触发表结构变更。

-- 读取目标列的 histogram，避免把其他表的同名字段混在一起
SELECT TABLE_SCHEMA,
       TABLE_NAME,
       COLUMN_NAME,
       HISTOGRAM
FROM INFORMATION_SCHEMA.COLUMN_STATISTICS
WHERE TABLE_SCHEMA = 'shop'
  AND TABLE_NAME = 'orders'
  AND COLUMN_NAME = 'status';

如果只想看几个关键字段，可以使用 MySQL 的 JSON 路径操作符：

-- 把桶数、采样比例和自动更新标记提取成可读列
SELECT
  HISTOGRAM->>'$."number-of-buckets-specified"' AS bucket_count,
  HISTOGRAM->>'$."sampling-rate"' AS sampling_rate,
  HISTOGRAM->>'$."auto-update"' AS auto_update
FROM INFORMATION_SCHEMA.COLUMN_STATISTICS
WHERE TABLE_SCHEMA = 'shop'
  AND TABLE_NAME = 'orders'
  AND COLUMN_NAME = 'status';

bucket_count 可以帮助确认桶数配置是否生效；sampling_rate 反映生成统计时读取数据的比例，1 表示读取了全部数据；auto_update 用于判断是否启用了自动更新。这里检查的是统计对象，不是通过查看表定义来判断。

数据变化频繁时选择自动更新

默认策略是手动更新。如果一个列的分布会随日常导入持续变化，可以在更新 histogram 时显式开启 AUTO UPDATE：

-- 生成 status 的 histogram，并允许后续统计维护自动刷新它
ANALYZE TABLE shop.orders
  UPDATE HISTOGRAM ON status WITH 32 BUCKETS
  AUTO UPDATE;

如果希望由发布脚本或维护窗口统一控制，则使用 MANUAL UPDATE，或者省略该子句，因为手动更新是默认行为：

-- 把更新策略切回手动，后续由维护任务明确触发
ANALYZE TABLE shop.orders
  UPDATE HISTOGRAM ON status WITH 32 BUCKETS
  MANUAL UPDATE;

自动更新并不等于每条写入都立即重建 histogram。它仍受 MySQL 统计维护机制控制。生产环境需要把更新策略、桶数和目标列记录在维护说明中，避免一边由自动机制维护、一边由脚本反复覆盖设置。

删除统计时只删除 histogram

如果某个列的 histogram 已经不适合当前数据分布，可以只删除它：

-- 只移除 status 列的 histogram，不删除列、索引或表中的数据
ANALYZE TABLE shop.orders
  DROP HISTOGRAM ON status;

删除后，优化器不再使用这份列 histogram；它不会把列定义或索引一起删除。需要重新建立时，再执行 UPDATE HISTOGRAM。更新或删除多个列时，仍然要明确写出列名，便于审计和回滚记录。

三个容易混淆的边界

第一，更新统计不是建索引。 histogram 能帮助估算过滤条件，但不会改变访问路径的物理结构。如果查询仍缺少合适索引，更新统计不能代替索引设计。

第二，表重命名和改列定义影响不同。 RENAME TABLE 会让 histogram 继续关联重命名后的表；删除或修改列的 ALTER TABLE 可能移除该列的 histogram。不要用改表来“刷新”统计。

第三，成功不代表一定读取全表。 生成 histogram 时如果估算内存超过 histogram_generation_max_mem_size，MySQL 可能采样数据。检查 sampling-rate，比只看返回的 status 更能说明本次统计的来源范围。

发布前可以保留的最小记录

如果这个动作由维护脚本执行，建议至少记录表名、列名、桶数、更新策略、执行时间和返回状态。这样下次查询计划变化时，能分辨是数据变化、统计刷新还是索引变更导致的。

-- 用固定查询留下当前策略的可追溯记录
SELECT
  TABLE_SCHEMA,
  TABLE_NAME,
  COLUMN_NAME,
  HISTOGRAM->>'$."number-of-buckets-specified"' AS bucket_count,
  HISTOGRAM->>'$."auto-update"' AS auto_update,
  HISTOGRAM->>'$."last-updated"' AS last_updated
FROM INFORMATION_SCHEMA.COLUMN_STATISTICS
WHERE TABLE_SCHEMA = 'shop'
  AND TABLE_NAME = 'orders'
  AND COLUMN_NAME IN ('status', 'amount');

结论很简单：不改表结构更新列分布统计，就对指定列执行 ANALYZE TABLE ... UPDATE HISTOGRAM，再从 COLUMN_STATISTICS 查看 JSON 结果。需要撤销时用 DROP HISTOGRAM，不要把统计维护和 DDL 混在一次变更里。

相关问题

histogram 会自动创建索引吗？ 不会。它只提供列值分布统计，索引仍需要单独设计。

为什么查询到的 sampling-rate 小于 1？ 生成统计时可能受内存上限影响而采样，sampling-rate 用于表示读取比例。

怎么只更新一个列？ 在 UPDATE HISTOGRAM ON 后只写该列名；其他列已有的 histogram 不会因为这次更新被替换。