直方图仅在列值分布严重不均、用于关键过滤条件且无有效索引时提升选择率估算精度；需按基数选singleton（低基数）或eq_height（高基数）类型，配合innodb_stats_persistent=on并验证元数据与explain预估变化。
ANALYZE TABLE ... UPDATE HISTOGRAM 不会让查询“自动变快”，但它能让优化器对 WHERE、JOIN 或 GROUP BY 条件中列的选择率（selectivity）估算得更准——这是执行计划改善的起点。
直方图只在优化器真正“猜不准”时才起作用
传统统计（如 cardinality、avg_length）对倾斜数据完全失效。比如 status 列中 95% 是 'active'，其余 15 种状态各占不到 1%，优化器仍会按“均匀分布”估算 WHERE status = 'cancelled' 返回约 1/16 的行数，导致它错误选择全表扫描而非索引查找（哪怕有索引）。直方图把这种偏差显式告诉优化器，让它知道 'cancelled' 实际只占 0.3%，从而更可能选对访问路径。
- 必须满足：列值分布严重不均 + 出现在关键过滤条件中 + 没有可用索引或未命中索引前导列
- 不满足任一条件，直方图不会被读取，EXPLAIN 中的
rows预估也不会变化 - 有索引且条件命中前导列时，优化器优先依赖索引统计，直方图基本闲置
建错类型或桶数，反而让优化器更迷糊
SINGLETON 和 EQ_HEIGHT 不是随便选的。用 EQ_HEIGHT 处理只有 4 个枚举值的 order_status 列，会把所有值强行塞进几个等频区间，丢失每个状态的真实频次；而用 SINGLETON 去处理 created_at（高基数、连续值），则会生成上万桶，元数据膨胀且加载变慢。
-
SINGLETON：适合低基数、离散值明确的列（如状态、类型、开关字段），桶数可设为唯一值数量 ±20% -
EQ_HEIGHT：适合时间戳、金额、用户 ID 等高基数列，桶数建议 100–256，超过 1000 显著拖慢解析 - 不指定
TYPE时默认EQ_HEIGHT，对枚举列大概率误判 - 字符串列若平均长度 > 200 字节，建直方图可能报
ER_TOO_LONG_STRING，需先SUBSTRING(col, 1, 100)截断
直方图生效与否，不能靠“命令没报错”判断
执行 ANALYZE TABLE t UPDATE HISTOGRAM ON col; 成功，不代表优化器用了它。真正验证要两步走：
- 查元数据：
SELECT HISTOGRAM FROM information_schema.COLUMN_STATISTICS WHERE TABLE_NAME = 't' AND COLUMN_NAME = 'col';—— 返回非空 JSON 才算写入成功 - 比预估：
EXPLAIN FORMAT=JSON SELECT * FROM t WHERE col = 'x';建直方图前后对比"rows"字段，变化明显（如从 12000 → 380）才说明被采纳 - 注意陷阱：如果查询里写了
WHERE UPPER(col) = 'X'或WHERE col + 0 > 100，直方图直接失效，因为优化器看到的是函数结果，不是原始列值 - 分区表、从库、
innodb_read_only=ON等环境限制也会让直方图形同虚设
它只是调优链条中的一环，不是银弹
直方图不改索引、不重写 SQL、不减少 I/O，它只影响优化器对“要扫多少行”的判断。一个查询没变快，大概率是因为：
- 该列其实有索引，但因隐式类型转换（如
BIGINT对VARCHAR）导致索引失效，此时建直方图毫无意义 - 数据变动频繁（如每小时百万级写入），但直方图半年没更新，统计严重过期
- 查询涉及多列组合条件，只给其中一列建了直方图，优化器仍无法准确估算联合选择率
- 执行计划瓶颈根本不在估算环节，而在磁盘 IO、锁等待或网络传输上
最常被忽略的点：直方图需要和 innodb_stats_persistent=ON 配合使用，否则 ANALYZE 后的统计可能很快被自动采样覆盖；另外，它只在 optimizer trace 的 range_analysis 或 considered_execution_plans 阶段悄悄参与决策，不会在 EXPLAIN 输出里打个标签告诉你“我用了直方图”。
