直方图选择性估计怎么配置或排查

MySQL 慢查询排查到一半，常会遇到一个尴尬现象：索引明明存在，优化器却把过滤结果估得过多或过少，最后选了不合适的访问路径。直方图选择性估计解决的是“列值分布不均匀，但现有索引统计不足”这一小块问题。它不会替代索引，也不会保证每条 SQL 都换计划。

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

先确认问题真的是选择性估计

假设订单表的 channel 列大多数值是 web，少量值是 partner。查询少量合作渠道订单时，如果优化器按均匀分布猜测，估计行数就可能偏离实际数量。先固定同一条 SQL 查看计划：

-- 用 JSON 计划保留估计行数，便于和实际查询结果对照
EXPLAIN FORMAT=JSON
SELECT order_id, created_at
FROM shop_order
WHERE channel = 'partner' AND created_at >= '2026-01-01';

记录过滤条件、预估 rows、访问类型和实际返回行数。若偏差只在某个非均匀分布列上反复出现，再考虑直方图；如果是缺少联合索引、表达式导致索引失效或统计信息整体过期，应该先处理那些根因。

用 UPDATE HISTOGRAM 配置目标列

直方图按列保存，创建或替换都通过 ANALYZE TABLE 完成。默认桶数是 100，也可以在 1 到 1024 之间指定；一次只处理当前表中列出的目标字段。

-- 先为分布偏斜的列生成 64 个桶，避免一次改动过多列
ANALYZE TABLE shop_order
  UPDATE HISTOGRAM ON channel WITH 64 BUCKETS;

-- 需要撤销时只删除 channel 的直方图，不影响其他列
-- ANALYZE TABLE shop_order DROP HISTOGRAM ON channel;

桶数不是越大越好。数据量小、取值集中时，64 或默认值通常已经足够；高基数且分布复杂的列可以在测试环境比较不同桶数，但不要把每次重建都安排在高峰期。直方图是持久化的列统计信息，重建会替换该列已有的结果。

从 COLUMN_STATISTICS 判断它是否有效

不要只看 ANALYZE TABLE 返回成功就结束。直方图信息可从 INFORMATION_SCHEMA.COLUMN_STATISTICS 读取；该视图会返回数据库、表、列以及 JSON 格式的 HISTOGRAM。

-- 读取指定列的直方图 JSON，确认统计对象没有查错库或表
SELECT SCHEMA_NAME, TABLE_NAME, COLUMN_NAME, HISTOGRAM
FROM INFORMATION_SCHEMA.COLUMN_STATISTICS
WHERE SCHEMA_NAME = DATABASE()
  AND TABLE_NAME = 'shop_order'
  AND COLUMN_NAME = 'channel';

重点看 JSON 中的 histogram-type、number-of-buckets-specified、sampling-rate 和 last-updated。查不到记录，可能是目标列没有直方图，也可能是当前账号看不到该列；先确认权限和表名。采样率小于 1 时，结果来自样本，重建两次可能出现细微差异，不要仅凭一次计划变化下结论。

重建之后用实际行数反向验证

重新运行原查询的 EXPLAIN，在可接受的测试窗口使用 EXPLAIN ANALYZE 对照实际执行结果。你要看的是估计行数是否更接近实际、访问路径是否适合，以及总耗时和锁等待有没有变差。计划改变只是中间证据，不是性能结论。

-- 只移除造成问题的列统计，先保留 EXPLAIN 对照记录
ANALYZE TABLE shop_order DROP HISTOGRAM ON channel;

当过滤条件涉及多个强相关列时，单列直方图不能表达列之间的联合分布；这时继续增加桶数通常不是答案。生产操作前保存旧计划、SQL 样本和复测结果，回退时也只回退这一个统计对象。

常见问题

直方图会自动给没有索引的列加速吗？

不会。它补充优化器的分布估计，不创建索引，也不改变查询必须扫描的数据量。

为什么更新直方图后执行计划没变？

可能原计划已经足够合理，或者该 SQL 的过滤形状没有使用这份列统计。应以估计与实际行数、耗时和访问路径一起判断。

桶数应该直接设为 1024 吗？

不建议。桶数需要结合数据量、分布复杂度和生成成本，在测试环境用同一组 SQL 做对比。