主从延迟导致读不到新数据是典型问题，根源在于复制延迟而非sql错误；需通过强制主库读、连接粘滞、等待位点、拆分大事务等手段保障一致性。
主从延迟导致 SELECT 读不到刚写的 INSERT/UPDATE
这是最典型的症状：应用写完主库，立刻去从库查，结果查不到或查到旧数据。根本原因不是SQL写得不对，而是复制本身有延迟，哪怕只有几十毫秒，在高并发或大事务场景下也足够出问题。
常见错误现象：INSERT INTO users ...; SELECT * FROM users WHERE id = LAST_INSERT_ID(); 在从库执行时返回空；或者订单创建后立即查列表，新订单不显示。
- 别依赖“写完就立刻可读”的假设，主从架构下这本身就是错的
- 读写分离中间件（如
ShardingSphere、MyCat）默认不保证会话一致性，需显式开启sticky connection或weak read consistency - 应用层简单方案：对刚写入的记录，强制走主库查，用标记位或上下文控制，比如加一个
force_master=true参数 - 避免在事务末尾立即发一个跨库的读请求——MySQL 的
read_committed隔离级别也无法解决主从延迟
LOAD DATA INFILE 或大事务引发从库 Seconds_Behind_Master 暴涨
这类操作本身在主库很快，但 binlog 是逐行回放的，从库单线程（MySQL 5.6 默认）或有限并行（5.7+）扛不住大批量变更，延迟直接升到分钟级。
使用场景：后台批量导入用户数据、日终对账补数、历史数据迁移。
- 主库执行前先
SHOW MASTER STATUS记下位点，从库用SELECT MASTER_POS_WAIT(...)等待追上，再继续后续逻辑（适合批处理脚本） - MySQL 5.7+ 开启
slave_parallel_workers > 0并设为slave_parallel_type = LOGICAL_CLOCK，但要注意：跨库 DML 仍可能串行 - 大事务拆成小事务提交，每 1000 行
COMMIT一次，减少单个 event 包体积和锁持有时间 - 避免在业务高峰期跑
LOAD DATA INFILE，它会阻塞 binlog dump 线程，间接拖慢其他从库同步
负载均衡器把读请求轮询到不同从库，造成“同一用户两次查询结果不一致”
这不是数据错误，而是体验断裂：用户刷新页面，第一次从库 A 返回旧昵称，第二次从库 B 还没同步到，返回更旧的昵称。用户觉得系统“抽风”。
本质是会话一致性（session consistency）缺失，而不仅仅是最终一致性。
- 不要用纯轮询（round-robin）分发读请求，改用基于用户ID、会话ID或SQL特征的哈希路由，确保同一批关联查询落在同一台从库
- 若用
ProxySQL，配置mysql-users表里的default_hostgroup+mysql-query_rules中的sticky_conn规则 - 应用层缓存（如 Redis）里存一份“最近写入时间戳”，读之前先比对从库的
SHOW SLAVE STATUS\G中的Seconds_Behind_Master，超阈值（如 > 1s）则切主库 - 注意：某些云数据库（如阿里云 RDS）的只读地址本身就做了连接粘滞，但文档里未必写清楚，得实测验证
从库 read_only=ON 被意外关闭或被 SUPER 权限绕过
一旦从库能写，主从数据必然分裂，后续任何延迟处理都失去意义。这不是性能问题，是数据安全红线。
容易被忽略的地方：运维手动修数据、监控脚本带 --defaults-extra-file 加了高权限账号、备份恢复后忘记重置 read_only。
- 永远在从库 my.cnf 里写死
read_only=ON和super_read_only=ON（MySQL 5.7+），后者防 SUPER 用户误写 - 定期巡检：用
SELECT @@read_only, @@super_read_only;，结果必须全为ON - 禁止给应用账号
SUPER权限，哪怕只读账号也只需REPLICATION CLIENT和SELECT - 云厂商控制台有时会“重置参数组”，导致
super_read_only被覆盖为 OFF，上线前务必复查
延迟不是bug，是主从架构的固有属性；真正危险的是把它当成可忽略的背景噪音。最常出问题的，往往不是大流量瞬间，而是凌晨三点那个没人盯的定时任务，悄悄把从库拖离同步轨道。
