主从复制延迟导致 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 的自动定位能力很强大，但一旦混入非同步写入，修复成本远高于预防。日常运维中，比监控延迟更值得花精力的，是守住“从库禁止写入”这条红线。
