主从切换后性能下降是因旧从库作为新主库仍处于惯性运行状态，需关闭read_only、清空relay log、预热buffer pool、清理复制线程及中间件缓存，并控制初期写入压力。
主从切换后性能下降，不是配置没切过来，而是旧从库（新主库）的执行路径、缓存状态、锁机制和复制残留全都还在“惯性运行”。直接切完就用，等于让一台刚跑完长距离马拉松的机器立刻冲刺——它需要重新热身、重建索引缓存、释放旧复制锁、适应新角色。
检查 read_only 是否真正关闭
很多团队只改了 server-id 和 log_bin，却忘了关 read_only。它默认是 ON，即使你手动执行 SET GLOBAL read_only = OFF，重启后也会恢复——必须在 my.cnf 里显式设为 read_only = OFF 并重启生效。
- 查当前值：
SELECT @@read_only;，返回 1 就还没放开写入 - 确认配置文件是否覆盖：
grep -i "read_only" /etc/my.cnf，必须是read_only = OFF或压根没这行（默认 OFF） - 注意：如果用了
super_read_only = ON，它会强制覆盖read_only，也得一并关掉
清空 relay log 并重置复制状态
切换后若没清理 relay log，SQL 线程仍可能尝试回放旧主库发来的 binlog，造成无意义的 IO 和 CPU 占用，甚至触发冲突报错（比如主键重复、表不存在）。
- 先停复制：
STOP SLAVE; - 删 relay log：
RESET SLAVE ALL;（5.7+ 推荐，清配置+日志；5.6 用RESET SLAVE;+ 手动删relay-log.index和 *.000* 文件） - 验证：
SHOW SLAVE STATUS\G中Relay_Log_File和Relay_Master_Log_File应为空，Seconds_Behind_Master显示 NULL
重建 innodb_buffer_pool 热度
原从库长期只读，buffer pool 里全是查询热点页；切为主库后，突然要处理大量写请求（INSERT/UPDATE），大量脏页刷盘、页分裂、自适应哈希重建，CPU 和 IO 瞬间拉满。
- 观察：
SHOW ENGINE INNODB STATUS\G查看Buffer pool hit rate，低于 95% 就说明冷热不均 - 不要等它自己暖机——用
SELECT * FROM table_name LIMIT 1;主动预热核心表（尤其大表、高频更新表） - 如果业务允许，切完立即执行一次
innodb_buffer_pool_dump_now = ON+innodb_buffer_pool_load_now = ON（需提前开启 dump_at_shutdown）
检查并禁用未清理的复制线程与监控任务
pt-heartbeat、zabbix 监控脚本、自定义延迟检测服务，常以“从库身份”持续连接原主库或轮询旧位置，切换后它们还在后台跑，消耗连接数、触发无谓网络请求、甚至误报故障。
- 查活跃连接：
SHOW PROCESSLIST;，过滤含pt-heartbeat、monitor、check_delay的用户 - 杀掉无关连接：
KILL [id]; - 检查 crontab 或 systemd service：
systemctl list-timers --all | grep -i heartbeat，停掉所有复制相关定时任务 - 特别注意：某些中间件（如 MaxScale、ProxySQL）可能还缓存着旧主从关系，需 reload 配置
最易被忽略的一点：切换后第一波写请求往往来自业务重试或补偿逻辑，这些 SQL 常带 FOR UPDATE 或跨多表事务，而新主库的锁等待队列还是空的，容易瞬间堆积。建议切换后前 5 分钟，主动降级非关键写入，或加一层轻量级限流，给 buffer pool 和锁管理器留出缓冲时间。
