主备切换后必须动态适配慢查询日志配置：两端需独立开启slow_query_log、使用隔离日志路径、统一long_query_time阈值，从库须启用log_queries_not_using_indexes；切换中通过SET GLOBAL即时生效，但slow_query_log_file需配置文件+重载；切换后须校准系统时间（≤100ms偏差）方可合并分析日志。
主备切换后，慢查询日志分析不能简单沿用旧配置——因为角色已变，原从库升为主库，原主库可能转为新从库或下线。日志配置必须随角色动态适配，否则关键慢 SQL 会漏记、时间错乱、路径冲突，导致分析失效。
切换前：确保双端独立开启且参数可迁移
主备切换不是“切完就完”，而是分析连续性的分水岭。切换前就要让两端都具备完整记录能力：
- 主库和从库必须各自启用 slow_query_log = ON，不能只开一端；MySQL 不同步慢日志开关，复制线程执行的语句是否记日志，完全取决于当前实例自身的配置
- 各自指定**独立的日志路径**，如 /var/log/mysql/master-slow.log 和 /var/log/mysql/slave-slow.log；共用路径会导致写入覆盖或权限冲突
- 从库务必开启 log_queries_not_using_indexes = ON，因读负载常落在从库，未走索引的查询更容易暴露性能隐患
- 确认 long_query_time 值一致（例如都设为 1.0），避免切换后同一条 SQL 在新主库上不被记录，仅因阈值不同而“隐身”
切换中：更新配置并重载，不依赖重启
切换操作本身应尽量平滑，避免服务中断。日志配置也需快速对齐新角色：
- 原从库升级为新主库后，立即检查并确认其 slow_query_log 仍为 ON；若之前是临时 SET 开启，切换后仍有效，但建议补写配置文件防止重启失效
- 原主库若降级为新从库，需同步开启其慢日志（若此前未开），并设置与原从库一致的 slow_query_log_file 路径（但不可与新主库共用）和 long_query_time
- 使用 SET GLOBAL 动态调整参数（如 SET GLOBAL slow_query_log = ON）可即时生效，无需重启；但注意 slow_query_log_file 在 MySQL 5.7+ 多数版本为只读变量，必须靠配置文件+重载（FLUSH LOGS 或重启）才能变更
切换后：统一时间基准，合并分析要校准
主备切换后，两台机器可能承担不同流量，日志时间戳若不同步，pt-query-digest 会误判为“不同 SQL”：
- 运行 ntpq -p 或 timedatectl status 检查主从服务器时间偏差；生产环境要求误差 ≤ 100ms，否则 pt-query-digest 合并分析时会出现时间错位，无法关联同一请求在主从上的表现差异
- 分析命令示例：pt-query-digest /var/log/mysql/new-master-slow.log /var/log/mysql/new-slave-slow.log；但前提是两台机器时间已同步，否则应先用 --since 和 --until 分段限定时间范围，再人工比对
- 重点关注切换窗口（如切换前后 5 分钟）内的日志突增：是否有大量锁等待、Rows_examined 激增、或某类 SQL 出现频率陡升——这些往往是切换引发的索引失效、连接重连、或缓存击穿信号
