mysql 8.0直方图需显式创建才生效，仅影响等值及简单范围查询的行数估算，不改变索引行为，对like、函数字段、多列组合条件无效，且依赖合理采样与bucket数量。
直方图不会自动触发，必须显式创建
MySQL 8.0 的直方图不是优化器默认启用的功能，即使你升级到 8.0，EXPLAIN 显示的执行计划也不会因为数据分布不均就“自动变聪明”。它只在你为特定列显式创建直方图后，才可能被优化器参考。创建语句是：ANALYZE TABLE t UPDATE HISTOGRAM ON c1, c2 WITH 16 BUCKETS;。注意：BUCKETS 数量并非越多越好——16 是常用起点，超过 100 后统计开销明显上升，且对大多数倾斜场景提升有限。
常见错误现象：ANALYZE TABLE 执行成功但执行计划没变化。原因可能是：列上已有索引（优化器仍倾向走索引），或直方图未覆盖查询中实际使用的值范围（比如只对 status 列建了直方图，但 WHERE status = 'processing' 这个值在采样时恰好没进桶）。
直方图只影响等值查询和简单范围查询的行数估算
它对 =、IN、BETWEEN 类型条件有作用，但对 LIKE '%abc'、函数包裹字段（如 YEAR(created_at)）、或跨列组合条件（如 WHERE a = ? AND b > ?）基本无效。优化器拿到的仍是单列独立分布，无法建模列间相关性。
使用场景举例：一张订单表中 order_status 列 95% 是 'completed'，其余 5% 均匀分布在 10 种状态。没直方图时，优化器认为每个状态约 10% 行数，可能误判 WHERE order_status = 'shipped' 会返回大量数据，从而放弃索引走全表扫描；建完直方图后，估算行数接近真实值（≈0.5%），更可能选择索引。
关键参数差异：WITH 16 BUCKETS 是等深直方图（每个桶行数大致相等），适合倾斜数据；MySQL 不支持等宽直方图。桶内具体值边界可通过查询 information_schema.COLUMN_STATISTICS 查看，但不能手动调整。
直方图不改变索引结构，也不替代索引设计
它只是让优化器“算得更准”，但不会让一个本该走索引的查询突然走错，也不会让一个本不该走索引的查询强行走索引。如果某列根本没有索引，建直方图毫无意义；如果索引本身选择性差（如布尔字段只有两个值），直方图也救不了执行计划。
容易踩的坑：
- 在高频写入表上频繁执行
ANALYZE TABLE ... UPDATE HISTOGRAM，会引发元数据锁等待，阻塞 DML - 误以为直方图能解决所有“索引没走”的问题，忽略了
SQL_NO_CACHE、force index或统计信息过期等更常见的原因 - 对
VARCHAR(255)类长文本列建直方图，MySQL 默认只采样前 42 字节，导致区分度丢失（可改用ANALYZE TABLE ... UPDATE HISTOGRAM ON c1 WITH 16 BUCKETS SAMPLE_SIZE 1000000提高采样精度）
验证直方图是否生效，别只看 EXPLAIN
EXPLAIN 的 rows 列变化是最直接信号，但要注意：它显示的是优化器预估行数，不是真实扫描行数。真正要看效果，得对比 EXPLAIN FORMAT=JSON 中的 "rows_estimation" 节点，里面会明确写出是否用了直方图（"histogram_type": "SINGLE_PREC_HB"）以及各桶的边界与频次。
另一个关键动作是强制清空查询缓存并测速：FLUSH OPTIMIZER_COSTS;（重置成本模型）+ SELECT SQL_NO_CACHE ...。否则可能因计划缓存掩盖直方图效果。如果加了直方图后 EXPLAIN 没变，但实际执行快了，说明优化器内部估算变了但计划决策逻辑没跳变——这种情况在多表 JOIN 中尤其常见，需要结合 optimizer_trace 看完整决策链。
复杂点在于：直方图效果高度依赖查询模式与数据倾斜形态。同一张表，对 status = 'failed' 有效，对 status IN ('failed','canceled') 可能失效——因为优化器对 IN 列表的估算策略不同，且直方图不保证桶边界正好卡在这些值上。
