直方图仅在无索引、数据分布严重倾斜且explain预估与实际行数相差超10倍的where字段上手动创建才有效；需先更新统计信息、避免函数包裹和分区误用，并通过information_schema.column_statistics验证json非空。
直方图不是“升级完就能自动生效”的功能，它只在特定条件下补救统计失准，且必须手动创建——升级本身不会触发任何直方图生成。
哪些字段值得建直方图
别给所有WHERE字段都建。只盯这三类：
- 字段出现在
WHERE里但没索引（比如status、category、order_type） - 值分布严重倾斜：某个值占比 > 85%，其余值散落在十几种状态里
-
EXPLAIN显示rows预估和实际扫描行数相差超10倍（例如预估12行，SELECT COUNT(*)查出来是15万行）
如果字段已有索引，或者数据基本均匀（如user_id、created_at），建直方图几乎无效，还白占元数据空间。
建直方图前必须确认的三件事
否则命令执行成功，但优化器根本不会用：
- 确认统计信息已最新：
ANALYZE TABLE orders;先跑一遍，否则直方图基于过期采样数据构建 - 字段不能被函数包裹：比如
WHERE UPPER(status) = 'ACTIVE'→ 直方图失效；必须写成WHERE status = 'active' - 避免在分区表上对未指定分区的查询建：MySQL 8.0.19+ 支持部分场景，但跨分区查询仍无法利用直方图
桶数（BUCKETS）怎么设才不翻车
桶数不是越多越好，设错反而让优化器更糊涂：
- 枚举类字段（如
status最多20个取值）：25–50BUCKETS足够，ANALYZE TABLE orders UPDATE HISTOGRAM ON status WITH 25 BUCKETS; - 字符串字段平均长度 > 200 字节（尤其
utf8mb4）：可能报错ER_TOO_LONG_STRING，需先截断：ANALYZE TABLE orders UPDATE HISTOGRAM ON SUBSTRING(status, 1, 100) WITH 25 BUCKETS;（注意精度损失） - 超过1000
BUCKETS不推荐：元数据体积暴涨，每次解析SQL都要加载，拖慢语句准备阶段
验证直方图是否真起效
别信Query OK，直接查元数据：
SELECT HISTOGRAM FROM information_schema.COLUMN_STATISTICS WHERE TABLE_NAME = 'orders' AND COLUMN_NAME = 'status';
返回非空 JSON（如{"buckets": [...], "data-type": "string"}）才算落库成功。之后再跑EXPLAIN，重点看rows预估值是否明显贴近真实扫描量——这才是直方图真正生效的唯一信号。
最易忽略的一点：直方图从不改变执行计划类型（比如不会把ALL变成ref），它只影响代价估算权重。如果优化器面前有两条路可选，直方图的作用是让它挑对那条更省的路；但如果只有一条路（比如全表扫描是唯一选项），它再准也没用。
