主从复制延迟导致读到旧数据时，强一致性读必须走主库；从库只读需回收SUPER权限并配置super_read_only；GTID模式下须严防errant transaction。
主从复制延迟导致 SELECT 读到旧数据怎么办
MySQL 主从默认异步复制，INSERT/UPDATE/DELETE 在主库执行成功后，从库可能还没应用 binlog，此时应用直接连从库查数据，就会看到过期状态。这不是 bug，是设计使然。
- 业务上能接受“最终一致性”的场景（如日志、统计报表），可继续读从库，但需在代码里明确注释该查询不保证实时
- 强一致性要求的读操作（如订单支付后立即查余额），必须走主库，或使用
SELECT ... FOR UPDATE+ 主库事务兜底 - 想折中？可用
SELECT SLEEP(0.1)等待短时间再查——不推荐；更靠谱的是监控Seconds_Behind_Master，超阈值（如 > 1s）时自动切主库 - 注意：
SHOW SLAVE STATUS中的Seconds_Behind_Master是估算值，大事务或网络抖动时可能不准，不能作为唯一判断依据
SET GLOBAL read_only = ON 在从库上没生效？
从库设为只读是防误写的基本操作，但常有人发现设了之后仍能执行 INSERT。根本原因是：只有 super 权限用户才被 read_only 限制，普通用户不受影响；而 root 默认有 super 权限。
- 正确做法：先执行
SET GLOBAL read_only = ON，再回收 root 或其他高权限账号的SUPER权限（用REVOKE SUPER ON *.* FROM 'user'@'host'） - 更安全的方式是用
super_read_only = ON（MySQL 5.7.8+），它会同时限制 super 用户的写操作 - 注意：这两个变量都只是会话级防护，重启后失效，必须写进配置文件
my.cnf的[mysqld]段落并重启 mysqld 才持久
主库 crash 后从库 Relay_Log_Pos 和 Exec_Master_Log_Pos 不一致怎么处理
这是典型的数据断点不一致问题：主库宕机前最后几条 binlog 没来得及传到从库，或从库已接收但没来得及执行完就中断了。此时 SHOW SLAVE STATUS 中两个位置点对不上，Slave_SQL_Running_State 可能卡在 “Reading event from the relay log”。
- 先确认主库恢复后最新的
File和Position（用SHOW MASTER STATUS） - 若从库 relay log 还完整，用
mysqlbinlog解析对应 relay log 文件，找到最后成功执行的 GTID 或 position，再用CHANGE MASTER TO ... MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy手动跳过损坏段 - 如果 relay log 已损坏或不确定，最稳妥是重建从库：停掉 SQL 线程 → 备份主库当前数据 → 在从库上
RESET SLAVE ALL→ 导入备份 →CHANGE MASTER TO指向主库最新位点 - 别依赖
SLAVE_SKIP_COUNTER跳过错误，它只跳过一个 event，且不适用于 GTID 模式
GTID 模式下 Errant transaction 导致主从无法切换
当从库手动执行了写操作（比如绕过 read_only），这个事务会在从库生成一个主库没有的 GTID，称为 errant transaction。后续如果做主从切换，新主库会拒绝来自旧主库的 binlog（因为 GTID 集合冲突），报错类似 The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires。
- 检查方法：在从库运行
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;，看是否有未执行的 GTID；再比对SELECT @@GLOBAL.GTID_EXECUTED;在主从之间的差异 - 修复方式：在从库执行
SET GTID_NEXT='xxx-yyy-zzz:nnn'; BEGIN; COMMIT;伪造一个空事务，把 errant GTID “占位”掉，再SET GTID_NEXT='AUTOMATIC' - 但伪造前必须确保该 GTID 确实没在主库执行过，否则会引发主键冲突或数据覆盖——所以生产环境强烈建议禁用从库写，并定期用
pt-table-checksum校验数据一致性
GTID 的自动定位能力很强大，但一旦混入非同步写入，修复成本远高于预防。日常运维中，比监控延迟更值得花精力的，是守住“从库禁止写入”这条红线。
