直方图仅在无索引、数据严重倾斜且优化器需列分布信息时有效；建错或未验证反而恶化执行计划。值得建的字段须同时满足：出现在where/join/group by中但无索引、值分布严重不均、explain预估行数与实际相差超10倍。
直方图不是“加了就快”，它只在无索引、数据严重倾斜、且优化器真需要列分布信息时才起作用；建错或没验证，反而让执行计划更差。
哪些字段值得建直方图？看这三点再动手
别给所有列都建——浪费资源还可能干扰优化器。只盯住同时满足以下条件的字段：
- 出现在
WHERE、JOIN或GROUP BY中，但该列没有索引（比如status、category、type） - 值分布严重不均：例如
status中'active'占 92%，其余 15 种状态共占 8% -
EXPLAIN显示预估行数（rows）和实际扫描行数相差超 10 倍（如预估 1 行，实际扫了 30 万行）
ANALYZE TABLE UPDATE HISTOGRAM 怎么写才有效
语法看着简单，参数错一个就白干：
- 标准写法：
ANALYZE TABLE orders UPDATE HISTOGRAM ON status WITH 25 BUCKETS;—— 桶数要按场景调，不是越多越好 - 多列必须重复写：
ANALYZE TABLE orders UPDATE HISTOGRAM ON status WITH 25 BUCKETS, UPDATE HISTOGRAM ON priority WITH 16 BUCKETS;，不能写成ON status, priority - 执行需
SELECT和INSERT权限；若启用了innodb_read_only=ON，会直接报错ERROR 1290 (HY000) - 执行期间持表级只读锁，长事务未结束时会被阻塞，务必避开高峰
为什么建了直方图，EXPLAIN 还没变？检查这三个盲区
直方图只是辅助基数估算，以下情况会让它彻底失效：
- 查询中对列用了函数，如
WHERE UPPER(status) = 'ACTIVE'—— 直方图基于原始列值构建，无法参与估算 - 表是分区表，且查询条件未命中具体分区（MySQL 8.0.19+ 修复部分场景，但仍有边界）
- 直方图建在从库上，但
information_schema.COLUMN_STATISTICS不复制，导致主从EXPLAIN行为不一致
怎么确认直方图真的被优化器用了？
别信命令是否成功，得看数据和执行计划是否变化：
- 查元数据：
SELECT HISTOGRAM FROM information_schema.COLUMN_STATISTICS WHERE TABLE_NAME = 'orders' AND COLUMN_NAME = 'status';—— 返回非空 JSON 才算写入成功 - 对比
EXPLAIN FORMAT=JSON：建直方图前后分别执行SELECT * FROM orders WHERE status = 'done';，重点看"rows"预估值是否明显贴近真实占比（比如从预估 10000 变成 240） - 注意：
filtered字段也会变——它反映选择率估算精度，直方图生效后会更接近真实过滤比例（不再是默认的 10% 或 33.33%）
真正容易被忽略的是：直方图不会改变执行计划类型（比如不会把 ALL 变成 ref），它只影响优化器在多个可用路径中选哪个代价更低。如果你的查询本就该走全表扫描，直方图再准也没法绕过这个事实。
