MySQL 8.4 直方图怎么修正错误估算：ANALYZE TABLE 与采样率核对

线上订单列表突然从 80 毫秒变成 1.8 秒，索引还在，SQL 也没有改。把查询拿到测试库里看，优化器把 status = 'PAID' 估成了几乎一半的订单，但真实数据里支付完成只占很小一部分。这个时候继续加索引，往往是在和错误的基数估算较劲。

为什么索引没变，计划却会选错

优化器做计划选择时并不知道每个值究竟出现了多少次，它依赖索引基数和列统计去估算过滤后的行数。订单表里的 status 是典型偏斜列：PENDING 可能占大多数，REFUNDED 只有很少记录。若统计信息把每个状态近似成均匀分布，某个状态的估算就会偏离真实值。

先把问题拆成两件事：索引是否能定位候选行，以及优化器是否知道这些候选行大概有多少。直方图只处理第二件事，所以它不是“让索引更快”的开关，也不该作为无条件的性能调优动作。

先用 EXPLAIN 记录错误估算

假设订单表已经有 idx_orders_status_created，查询只取最近的已支付订单：

EXPLAIN FORMAT=JSON
SELECT id, user_id, paid_at
FROM orders
WHERE status = 'PAID'
  AND paid_at >= '2026-08-01'
ORDER BY paid_at DESC
LIMIT 50;

不要只盯着 key。把 rows_examined_per_scan、过滤比例和实际抽样结果一起记录下来，尤其要保存生成统计信息前后的同一份计划。若只是偶尔抖动，先确认表数据是否刚经历了大批量导入、归档或状态迁移，别急着直接改桶数。

用 ANALYZE TABLE 生成列直方图

MySQL 8.4 支持通过一条 ANALYZE TABLE 语句管理列直方图。下面先给 status 生成 32 个桶：

ANALYZE TABLE orders
  UPDATE HISTOGRAM ON status
  WITH 32 BUCKETS;

不写桶数时默认是 100，允许范围是 1 到 1024。桶数不是越大越好：状态值很少时，32 个桶已经足够；对高基数列盲目增加桶数会提高统计生成成本，也会让排查变得不直观。

生成动作返回成功，不代表计划一定变好。下一步要确认统计对象真的写入数据字典：

SELECT SCHEMA_NAME, TABLE_NAME, COLUMN_NAME,
       HISTOGRAM->>'$."histogram-type"' AS histogram_type,
       HISTOGRAM->>'$."sampling-rate"' AS sampling_rate,
       HISTOGRAM->>'$."number-of-buckets-specified"' AS bucket_count
FROM INFORMATION_SCHEMA.COLUMN_STATISTICS
WHERE TABLE_NAME = 'orders'
  AND COLUMN_NAME = 'status';

sampling-rate 低时，先别急着相信结果

直方图生成可能因为内存上限而采样。sampling-rate 等于 1，表示这次读取了全部数据；小于 1，说明统计基于样本，极少数状态值有可能没有被充分捕捉。大表上出现采样并不一定是错误，但它需要和业务分布一起判断。

可以把统计结果、生成时间和主要查询计划存到变更记录里，再在低峰期重复一次生成动作。两次桶分布差异很大时，应先检查数据是否仍在快速变化，或者调小范围、换一个更稳定的候选列，而不是立刻把生产环境的桶数调到 1024。

什么时候应该删除直方图

如果更新统计后计划没有改善，或者统计让某条稳定查询频繁改变路径，可以先保留变更记录，再删除该列的直方图回到原有状态：

ANALYZE TABLE orders
  DROP HISTOGRAM ON status;

删除后重新查看 INFORMATION_SCHEMA.COLUMN_STATISTICS，确认该列记录已经消失，再用同一条 EXPLAIN 做前后对比。这个回退只移除直方图，不会删除索引，也不会改动订单数据。

还有一个容易混淆的点：直方图更新和普通的 ANALYZE TABLE orders 不是同一个动作。前者管理指定列的分布统计，后者主要更新表和索引的统计信息。遇到索引基数过期时，不能只靠直方图掩盖基础统计问题。

这些列不适合直接生成直方图

• JSON 列不支持生成直方图；如果筛选 JSON 路径，应先评估生成列和索引。
• 临时表、空间类型和加密表不能按这条路径生成直方图。
• 被单列唯一索引覆盖的列没有必要再用直方图描述选择性。
• 大批量变更后，统计信息可能很快过时，要把重建动作放进数据变更后的维护流程。

这些限制决定了排查顺序：先确认列类型和索引属性，再决定是否做统计实验；不要把每一次“估算不准”都归结为缺少直方图。

常见问题

直方图会替代索引吗？

不会。它补充列值分布，帮助优化器估算过滤结果；访问路径仍需要索引或表扫描来完成。

桶数应该设置多少？

从能表达业务分布的较小值开始。低基数状态列可以从 16 或 32 观察，高基数列再结合 sampling-rate 和计划稳定性调整。

为什么生成成功，查询还是慢？

可能是瓶颈在排序、回表、锁等待或磁盘读，而不是行数估算。用同一份计划和慢查询指标拆开验证，不要只看直方图是否存在。

删除直方图会丢数据吗？

不会。DROP HISTOGRAM 只删除列统计信息，索引、表数据和业务写入不受影响。

把统计修正变成可回退的小实验

一个稳妥的顺序是：保存原始 EXPLAIN，生成较小桶数的直方图，核对 COLUMN_STATISTICS 与 sampling-rate，再在同一数据条件下复查计划和耗时。只有估算更接近、计划更稳定、业务指标没有副作用时，才把它纳入维护流程；否则删除直方图，回到索引和 SQL 本身继续查。