主从执行计划不一致90%以上源于统计信息未对齐：innodb_stats_auto_recalc关闭导致从库统计停更，需主从均设on并持久化；read_only不限制临时表，须配合super_read_only；optimizer_switch参数必须完全一致。
主从执行计划不一致，90%以上是统计信息没对齐，不是SQL写得有问题，也不是索引建错了。
innodb_stats_auto_recalc 关闭后，从库统计信息就“停更”了
MySQL 5.6.6+ 默认开启 innodb_stats_auto_recalc，但升级或手动初始化从库时容易漏配。一旦关掉，InnoDB 就不再自动触发统计信息更新——哪怕表数据已增删百万行，INNODB_TABLESTATS.n_rows 仍显示旧值。
- 检查命令：
SELECT @@innodb_stats_auto_recalc;，主从都应为ON - 若为
OFF，别只改变量：需配合SET GLOBAL innodb_stats_auto_recalc = ON;并确认持久化（写入配置文件） - 注意：该参数仅对
innodb_stats_persistent = ON的表生效；若仍是OFF，统计信息根本不会落盘，重启即丢
FLUSH TABLE 操作会清空 modified_counter，导致自动收集永远不触发
很多备份脚本习惯性执行 FLUSH TABLES WITH READ LOCK，这会强制重载表定义（table share），顺手把 stat_modified_counter 归零。结果就是：每天改 10 万行，但 counter 总在归零前卡在 9 万，永远达不到“总行数 × 10%”的触发阈值。
- 验证方法：
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 不拦临时表，污染从库优化器决策路径
从库设了 read_only = ON，但 CREATE TEMPORARY TABLE、INSERT INTO ... SELECT 隐式临时表仍可执行。这些表不写 binlog，却会影响 EXPLAIN 对中间结果集大小的估算，进而让优化器选错连接顺序或索引。
- 监控信号：
SHOW GLOBAL STATUS LIKE 'Created_tmp_tables';持续上涨，尤其在从库执行报表类 SQL 后 - 真正只读需两步：
SET GLOBAL read_only = ON;→SET GLOBAL super_read_only = ON;（后者才禁临时表） - 应用层必须规避：
SELECT ... INTO OUTFILE、SELECT ... INTO DUMPFILE等语句在从库运行等于埋雷
optimizer_switch 参数不一致，连“是否用索引合并”都可能分道扬镳
optimizer_switch 是个逗号分隔的开关字符串，控制着索引合并、ICP、MRR 等底层行为。主从若有一项不同（比如主库开了 index_merge=on，从库关了），即使统计信息完全一样，EXPLAIN 输出的 type 和 key 也可能天差地别。
- 检查命令：
SELECT @@optimizer_switch;，逐项比对主从输出，重点关注index_merge、mrr、batched_key_access - 修改方式：统一写入配置文件
my.cnf的[mysqld]段，避免仅用SET GLOBAL（重启失效） - 特别注意：MySQL 8.0.22+ 默认关闭
condition_fanout_filter，老版本默认开，跨版本主从务必核对
统计信息不是“查一下就准”的静态快照，它依赖后台线程、计数器状态、持久化开关和全局配置四者咬合。最容易被忽略的是 FLUSH TABLE 对计数器的隐式清零，以及 read_only 对临时表的放行——这两点不解决，光刷 ANALYZE TABLE 只是反复擦黑板。
