MySQL 8.4 采样率怎么看：直方图统计的复查与回退

线上订单列表突然从 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 路径里的字段，应该先评估生成列搭配普通索引的方案。
• 临时表、空间类型字段和加密表不能按这套流程生成直方图。
• 被单列唯一索引覆盖的列，本身选择性已经是100%，完全没必要再用直方图额外描述。
• 大批量数据变更之后，统计信息很可能很快就过时，要把直方图重建动作放进大表数据变更后的固定维护流程。

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

常见问题

直方图会替代索引吗？

不会。它只补充列值分布信息，帮优化器更准确估算过滤后的返回行数；实际数据的访问路径还是要靠索引或者全表扫描来完成。

桶数应该设置多少？

从能表达业务分布特征的较小值开始测试就行。低基数的状态类列可以先从16或32开始观察效果，高基数列再结合 sampling-rate 和执行计划的稳定性逐步调整。

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

可能瓶颈在排序、回表、锁等待或者磁盘随机读，根本不是行数估算的问题。用完全相同的执行计划和慢查询指标拆开逐层验证，不要只盯着直方图是否存在找原因。

删除直方图会丢数据吗？

不会。DROP HISTOGRAM 只删除对应的列统计信息，索引、表数据和后续的业务写入完全不会受到影响。

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

一套稳妥的操作顺序是：先保存原始的EXPLAIN计划，生成小桶数的直方图，核对 COLUMN_STATISTICS 里的内容和 sampling-rate 参数，再在完全相同的数据条件下复查执行计划和实际耗时。只有估算更贴近真实值、计划更稳定、全链路业务指标没有副作用时，才把它纳入长期维护流程；否则直接删除直方图，回到索引和SQL本身继续排查问题。