同一条sql主从执行计划不同90%以上源于统计信息未对齐：innodb_stats_auto_recalc关闭致从库统计停更、read_only不限制临时表干扰估算、optimizer_switch参数不一致；需主从均设on并持久化、启用super_read_only、确保开关完全相同。
同一条SQL在主库和从库上执行计划不同，90%以上不是SQL或索引的问题，而是统计信息没对齐——innodb_stats_auto_recalc 关闭、optimizer_switch 不一致、或临时表干扰了优化器估算。
为什么 innodb_stats_auto_recalc 关掉会让从库“固守旧计划”
该参数控制InnoDB是否自动更新统计信息（比如 mysql.innodb_table_stats.n_rows）。MySQL 5.6.6+ 默认为 ON，但手动搭建从库、升级或用某些备份工具初始化时容易漏配成 OFF。
-
OFF后，哪怕表数据已增删百万行，n_rows仍卡在旧值，优化器基于错误基数选错连接顺序或索引 - 检查命令：
SELECT @@innodb_stats_auto_recalc;，主从都应返回ON - 改完变量后必须写入配置文件（如
my.cnf），否则重启失效；仅SET GLOBAL不持久 - 注意前提：
innodb_stats_persistent = ON必须开启，否则统计信息根本不落盘，auto_recalc形同虚设
为什么 FLUSH TABLES WITH READ LOCK 会让统计信息“永远不更新”
很多备份脚本习惯加这句，但它会重载表定义并清空 stat_modified_counter。而InnoDB自动收集的触发条件是：修改行数 ≥ 表总行数 × 10% —— counter 归零后，每天改9万行，只要总行数超90万，就永远达不到阈值。
- 验证方法：
SELECT database_name, table_name, n_rows, last_update FROM mysql.innodb_table_stats WHERE table_name = 'your_table';，对比主从last_update时间差 - 临时救急可用
ANALYZE TABLE your_table;，但大表会加读锁，高峰期慎用 - 根治办法：备份改用
mysqldump --single-transaction或 Percona XtraBackup，避开所有FLUSH类操作
为什么 read_only = ON 挡不住临时表，却能毁掉执行计划
从库设了 read_only = ON，但 CREATE TEMPORARY TABLE 和 INSERT INTO ... SELECT 隐式生成的临时表仍可执行。这些表不写 binlog，却参与优化器对中间结果集大小的估算——一旦报表类SQL在从库跑一次，后续关联查询可能因误判数据量而放弃走索引。
- 监控信号：
SHOW GLOBAL STATUS LIKE 'Created_tmp_tables';，若从库持续上涨，尤其在执行完复杂查询后，大概率是临时表污染了统计路径 - 真正只读需两步：
SET GLOBAL read_only = ON;→SET GLOBAL super_read_only = ON;（后者才禁临时表） - 应用层也得规避：
SELECT ... INTO OUTFILE、SELECT ... INTO DUMPFILE在从库运行等于埋雷
为什么 optimizer_switch 差一个开关，执行计划就分道扬镳
这是个逗号分隔的字符串开关集合，控制着索引合并、哈希连接、物化子查询等关键行为。主从只要其中一项不一致（比如主库开了 hash_join=on，从库关了），优化器就可能完全换一套逻辑选路。
- 检查命令：
SELECT @@optimizer_switch;，逐项比对主从输出是否完全相同 - 常见高危项：
index_merge=on、mrr=on、batched_key_access=on，任一开关状态不同都可能导致type从ref退化为ALL - 修改后需重启连接或执行
FLUSH OPTIMIZER_COSTS;（MySQL 8.0.22+）让新配置生效
最容易被忽略的是：统计信息不一致本身不会报错，EXPLAIN 看起来一切正常，但实际执行时扫描行数、临时表使用、排序开销全都不一样——问题往往要等到业务慢查询告警或主从延迟飙升才暴露出来。
