主从切换时性能风险点包括连接重连失败、新主库缓冲池未预热致查询变慢、旧主误收写请求；标准流程需确认同步位点一致、锁表、切流、回挂为从；强一致需半同步+MASTER_POS_WAIT+应用暂停事务；规避失误须dry-run、禁直接改配置、监控SQL状态与GTID差值、定期倒换演练。
主从切换时的性能风险点
主从切换瞬间容易引发性能抖动，核心在于连接重连、查询重试和缓存失效。客户端未配置自动重连或超时过短，会大量报错；新主库若无预热，缓冲池空、执行计划未缓存，首次复杂查询可能慢数倍；部分应用在切换后仍向旧主（已降为从）发写请求，触发拒绝错误，进一步拖慢响应。
标准切换流程（手动+半自动）
生产环境推荐“可灰度、可回退”的分步切换：
- 确认从库Seconds_Behind_Master = 0且IO/SQL线程均为Yes
- 在原主库执行FLUSH TABLES WITH READ LOCK，阻断新写入并记下SHOW MASTER STATUS的位点
- 在目标从库执行STOP SLAVE，核对Exec_Master_Log_Pos与原主位点一致
- 提升目标从库为新主：RESET MASTER + 应用层切流（如VIP漂移、DNS更新或配置中心下发）
- 原主库解除锁：UNLOCK TABLES，再将其配置为新主的从库，开启复制
数据一致性保障关键动作
仅靠Seconds_Behind_Master = 0不能保证强一致——它只反映中继日志执行进度，不包含网络延迟、事务提交顺序等细节。
- 启用semi-sync replication（半同步），确保至少一个从库落盘才返回客户端成功，降低切换时丢失事务概率
- 切换前在原主库执行SELECT MASTER_POS_WAIT('xxx', nnn)，等待指定位点被从库执行完毕，比轮询Seconds_Behind_Master更精确
- 应用层配合：写操作加FOR UPDATE或使用XA事务的场景，需在切换窗口期暂停，避免分布式事务跨主从断裂
- 切换后立即校验关键表的CHECKSUM TABLE或行数/聚合值，快速发现静默不一致
规避人为失误的实用建议
多数故障源于操作疏漏而非技术瓶颈：
- 所有切换脚本必须带--dry-run模式，先模拟输出将执行的SQL和影响范围
- 禁止直接修改my.cnf后重启mysqld切换角色；一律通过CHANGE MASTER TO动态调整
- 监控项需覆盖：Slave_SQL_Running_State（是否卡在DDL）、Retrieved_Gtid_Set与Executed_Gtid_Set差值（GTID模式下更准）
- 定期演练“强制主从倒换”，验证切换脚本、监控告警、应用容错能力，不依赖文档临场发挥
