直方图仅在列值分布严重不均匀且查询常命中高频/低频值时才显著影响执行计划；需结合数据分布、查询模式选择类型，及时更新，并警惕与绑定变量、索引的冲突。
直方图什么时候真有用
直方图只在列值分布严重不均匀、且查询条件常落在少数高频值上时才显著影响执行计划。比如用户表的 status 列：95% 是 'active'，3% 是 'inactive'，其余 2% 分散在十几种状态里——这时优化器靠默认的均匀分布假设会严重低估 WHERE status = 'deleted' 的返回行数，从而选错索引或走全表扫描。
常见错误现象：EXPLAIN 显示预估行数（rows）和实际相差 10 倍以上，尤其在 = 或 IN 查询高频/低频值时；加了索引但没走，或者走了索引却比全表扫描还慢。
- Oracle 默认不自动收集直方图，必须显式指定
method_opt（如'FOR COLUMNS status SIZE 254'） - PostgreSQL 从 v10 起默认对小表自动建直方图，但大表需调高
default_statistics_target（建议 100–500），再ANALYZE - MySQL 的
HISTOGRAM（v8.0+）需手动创建：ANALYZE TABLE users UPDATE HISTOGRAM ON status;，且仅支持等值查询优化，范围查询无效
怎么判断该不该建、建哪种类型
别一上来就堆 SIZE AUTO 或全列直方图。先看数据分布和查询模式：用 COUNT(*) GROUP BY 快速探查值频次，再结合慢查询日志里反复出现的谓词值。
使用场景决定类型选择：
-
频率直方图（Frequency Histogram）：当不同值总数 ≤ 直方图桶数（如 Oracle 的
SIZE 254），每个桶对应一个具体值。适合枚举类字段（status、gender） - 高度平衡直方图（Height-balanced）：旧版 Oracle 默认，现已基本被替代；值多于桶数时强行合并，丢失低频值精度，容易误导优化器
- PostgreSQL 和 MySQL 只支持等价于频率直方图的结构，不区分类型，但桶数不足时会合并相邻值区间——这正是非均匀数据下误差来源
参数差异关键点：SIZE（Oracle）、default_statistics_target（PG）、histogram_size（MySQL）不是越大越好。桶数翻倍不会线性提升精度，反而增加统计信息体积和 ANALYZE 时间；生产环境建议从 50 开始试，再根据 DBA_TAB_HISTOGRAMS 或 pg_stats 中的 most_common_vals 覆盖率调整。
统计信息更新不及时导致直方图失效
直方图不是一劳永逸的。数据批量导入、状态批量更新（如运营发券后大量用户 status 从 'pending' 变成 'issued'）后，旧直方图会立刻失准——优化器仍按“老分布”估算，执行计划退化。
性能影响明显：某电商订单表 order_status 直方图未更新，促销期间 WHERE order_status = 'shipped' 查询从 200ms 涨到 3s，因为优化器误判该值只占 0.1%，拒绝走索引。
- Oracle：监控
DBA_TAB_MODIFICATIONS，对变更率 >10% 的表触发DBMS_STATS.GATHER_TABLE_STATS，避免用ESTIMATE_PERCENT => AUTO（它可能采样过少） - PostgreSQL：设置
track_counts = on+ 定期VACUUM ANALYZE，或用pg_stat_monitor扩展识别统计滞后表 - MySQL：没有自动触发机制，必须在 ETL 脚本末尾加
ANALYZE TABLE；注意ANALYZE会锁表（8.0.23+ 支持INPLACE模式，但直方图仍需独占元数据锁）
直方图和索引、绑定变量的冲突点
直方图本身不改变索引结构，但它让优化器更“相信”某个谓词的选择率，从而放大索引误用风险。最典型的是绑定变量 + 直方图：同一 SQL 语句用不同值执行，因直方图存在，优化器可能为 :status = 'active' 生成全表扫描计划，为 :status = 'deleted' 生成索引范围扫描——而 Oracle 的游标共享机制可能固化其中一个计划，导致“窥视”失效。
容易踩的坑：
- SQL Server 不支持传统直方图，它的统计信息本身就是直方图形式，但默认只存 200 个桶，且无法手动扩展；遇到倾斜数据必须用
UPDATE STATISTICS ... WITH FULLSCAN - Oracle 中
bind peeking在直方图存在时更敏感，开启OPTIMIZER_ADAPTIVE_STATISTICS可能引发计划抖动，不如关掉并改用 SQL Plan Baseline - 所有数据库中，直方图对
LIKE '%xxx'、函数索引（UPPER(name)）完全无效——它只作用于原始列值分布
真正难的不是建直方图，是持续跟踪哪些列的分布正在漂移、哪些查询因统计偏差悄悄变慢。没有监控的直方图，很快就会变成执行计划里的幽灵。
