mysql 8.4 lts默认启用新优化器，但需手动配置innodb_stats_persistent=on、调整histogram_type与内存参数、验证直方图生成，并审慎开关optimizer_switch子项，否则易因统计缺失或偏差导致性能下降。
MySQL 8.4 LTS 默认启用新的优化器行为（基于代价的统计增强与直方图支持），但**不等于开箱即用就能获得最佳效果**——很多生产环境仍需手动确认或微调关键参数，否则可能因统计偏差、直方图未加载、或旧查询计划缓存残留导致性能倒退。
innodb_stats_persistent 和 innodb_stats_auto_recalc 必须显式检查
MySQL 8.4 要求持久化统计信息才能发挥新版优化器优势，而这两个参数在升级后不会自动继承旧值：
-
innodb_stats_persistent必须为ON（默认值），否则每次重启后统计清空，优化器反复“瞎猜” -
innodb_stats_auto_recalc默认为ON，但若表数据变更频繁（如每小时增删超 10% 行），建议保持开启；若为只读报表库，可设为OFF避免无谓开销 - 执行
ANALYZE TABLE t1后，检查information_schema.INNODB_SYS_TABLESTATS中STATS_INITIALIZED是否为Done，不是则说明持久化未生效
histogram_type 和 histogram_generation_max_mem_size 影响直方图质量
MySQL 8.4 的优化器依赖列直方图做更准的基数估算，但直方图默认不自动生成，且内存限制易被忽略：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
histogram_type默认是SINGLE_PREC_HB（单精度高度平衡），对高基数列（如用户ID）不够准；高要求场景可设为DOUBLE_PREC_HB -
histogram_generation_max_mem_size默认仅65536字节（64KB），小于此值的列才生成直方图；大表的关键过滤字段（如order_status）常被跳过，建议按需调高至262144（256KB） - 生成直方图命令：
ANALYZE TABLE orders UPDATE HISTOGRAM ON status, created_at；注意该操作会加表级读锁，避开业务高峰
optimizer_switch 中几个关键子项容易被忽略
新版优化器逻辑由 optimizer_switch 控制开关组合驱动，部分子项在 8.4 中默认启用，但某些 OLTP 场景反而需关闭：
-
condition_fanout_filter=on（默认开启）：启用条件扇出预估，对复杂 WHERE 有效，但极少数嵌套子查询场景会误判，可临时关掉验证 -
semijoin=on和materialization=on是 8.4 优化器提速主力，除非遇到特定半连接死循环 bug（见 Bug #112943），否则不建议关 -
hash_join=on默认开启，但在内存紧张或小表 JOIN 场景下，BNL（块嵌套循环）可能更稳；可通过EXPLAIN FORMAT=TREE观察是否真用了 hash join
真正麻烦的不是参数本身，而是统计信息和直方图的“冷启动”——刚升级完不做 ANALYZE TABLE，又没开 innodb_stats_auto_recalc，优化器就只能靠过期采样估算，这时候看 EXPLAIN 显示的 rows 常常偏差 10 倍以上。别信默认值，先查 INFORMATION_SCHEMA.STATISTICS 和 INNODB_SYS_COLUMNS 确认统计是否就位。
