读写分离下“刚写完就读不到”是异步复制的必然结果，非故障；根本原因是主库写入、binlog落盘、从库io拉取、sql回放四步存在不可消除的时间差，需通过强制主库读、会话绑定、延迟感知及压低延迟水位应对。
读写分离架构下，主从数据复制天然不一致——这不是故障，而是异步复制的必然结果。 你看到的“从库查不到刚写入的数据”，大概率不是配置错了，而是没理解 MySQL 复制链路的时序和边界。
为什么 SELECT 立刻查不到刚 INSERT 的数据？
这是最常被当成“bug”的现象。根本原因在于：主库写完提交、Binlog落盘、从库 IO 线程拉取、SQL 线程回放，这四步存在不可消除的时间差。
常见场景：
- 应用在主库执行
INSERT INTO orders ...后，立刻发请求到从库查SELECT * FROM orders WHERE id = ?—— 此时从库可能还没收到或还没执行这条语句； - 主库高并发写入（如批量导入），
Seconds_Behind_Master突然跳到几百秒，从库明显滞后； - 跨机房部署（如主在北京、从在深圳），网络 RTT 高、丢包多，IO 线程频繁重连或超时。
关键判断点：SHOW SLAVE STATUS\G 中 Slave_IO_Running 和 Slave_SQL_Running 都为 Yes，但 Seconds_Behind_Master > 0，就属于正常延迟，不是中断。
slave_parallel_workers 开了反而报错 1032？
MySQL 5.7+ 默认启用基于逻辑时钟的并行复制（slave_parallel_type=LOGICAL_CLOCK），但它对表结构有隐含要求：必须有主键或唯一索引。否则 SQL 线程无法安全拆分事务并行执行。
典型错误：
- 报错信息：
Error_code: 1032; Can't find record in 'xxx'; handler error HA_ERR_KEY_NOT_FOUND； - 触发条件：表无主键 +
slave_parallel_workers > 1+ 执行UPDATE或DELETE； - 底层原因：RBR 模式下 Binlog 记录的是行变更的物理位置（如主键值），没主键时依赖 InnoDB 隐式
row_id，而该 ID 在主从库各自维护，不一致导致定位失败。
解决路径：
- 优先加主键：
ALTER TABLE t ADD PRIMARY KEY (id);； - 临时规避：设
slave_parallel_workers = 1（牺牲性能换稳定）； - 绝对不要用
SET GLOBAL sql_slave_skip_counter = 1跳过——掩盖问题，后续可能放大不一致。
从库被写入后，怎么识别和修复“人为污染”？
只要从库没设 read_only = ON，任何有权限的账号都可能误执行 INSERT/UPDATE/DELETE，这类操作不会记入 Binlog，也不会同步回主库，造成静默不一致。
识别信号：
-
SHOW SLAVE STATUS\G中Exec_Master_Log_Pos不动，但Relay_Log_Space持续增长（说明 IO 线程还在收日志，SQL 线程卡住或跳过了）； - 对比主从库同一张表的
CHECKSUM TABLE t值不同； - 监控发现从库的
Com_insert、Com_update计数非零（主库应远高于从库）。
修复原则：
- 先停复制：
STOP SLAVE;； - 查从库最近的写操作：
SELECT * FROM performance_schema.events_statements_history_long WHERE sql_text LIKE '%t%' ORDER BY event_id DESC LIMIT 10;； - 若确认是误操作且不可逆，用
pt-table-sync工具反向同步（需提前授权REPLICATION CLIENT和PROCESS权限）； - 长期防护：在从库配置中强制启用
read_only = ON，并确保复制账号有SUPER权限才能临时关闭它。
真正难处理的不是“延迟几秒”，而是“不知道哪条数据不一致”。一旦怀疑不一致，别靠肉眼比对，用 pt-table-checksum 定位差异行，再决定是修复还是重建从库——后者看似重，但在生产环境里，有时比逐条修更可靠、更可预期。
