seconds_behind_master为0仍可能读到旧数据，因其仅反映io与sql线程间时间差，不包含大事务内部执行耗时；主库大事务未完全回放时，从库数据实际滞后。
主从延迟高导致读写分离数据不一致，不能靠“等”或“重试”来掩盖，必须从同步机制、事务粒度和读路由逻辑三处动手——否则任何缓存层或前端延时都只是给问题裹糖衣。
为什么 seconds_behind_master 为 0 还可能读到旧数据？
这个值只反映 IO 线程拉取 binlog 和 SQL 线程执行之间的“时间差”，但不包含事务内部的执行耗时。比如主库一个大事务写了 10 万行，seconds_behind_master 可能刚显示 0，但从库 SQL 线程还在 replay 这个事务的最后几条语句，此时查该表仍看不到最新状态。
- GTID 模式下更可靠：对比
Retrieved_Gtid_Set和Executed_Gtid_Set，差集才是真实未应用事务 - 心跳表法最贴近业务：在主库定时插入
INSERT INTO heartbeat (ts) VALUES (NOW(6))，从库 SELECT 后用NOW(6) - ts算出真实延迟 - 避免依赖
show slave status单一指标，尤其在并行复制开启后，seconds_behind_master可能长期为 0 但局部表仍滞后
并行复制不是开个开关就完事：必须配对调整 slave_parallel_type 和 slave_parallel_workers
MySQL 5.7+ 默认 slave_parallel_type = DATABASE，仅对跨库操作有效；若业务集中在单库多表（如 shop_db），它完全不生效。真正起效的是 LOGICAL_CLOCK 模式，但需同时满足两个条件：
- 主库开启
binlog_transaction_dependency_tracking = WRITESET（推荐）或COMMIT_ORDER - 从库设置
slave_parallel_workers > 0，且建议设为 CPU 核数的 1.5 倍（如 8 核设 12），不能盲目设 32 - 检查
SHOW PROCESSLIST中是否有多个Slave_worker线程处于Waiting for an event from Coordinator状态——说明并行没跑起来，大概率是主库没启用 writeset
大事务是延迟放大器：拆分比优化更直接有效
一个耗时 8 秒的单事务更新 50 万用户积分，在从库上会卡住整个 SQL 线程（即使开了并行），因为它无法被拆解为独立子事务。与其花半天调优索引或 buffer pool，不如从源头控制：
- 写入端改
INSERT ... VALUES (...), (...), (...)为每 1000 行一个事务，加COMMIT - 避免在事务中混入
SLEEP()、远程 HTTP 调用、大字段UPDATE等非数据库操作 - DDL 操作单独切窗口执行：
ALTER TABLE t ENGINE=INNODB, ALGORITHM=INPLACE, LOCK=NONE仍会阻塞复制流，应避开高峰并提前在从库STOP SLAVE手动同步
读请求不该无脑打从库：按事务上下文做路由决策
用户刚提交订单，后续查订单详情必须走主库；但查“历史订单列表”可以走从库。这种判断不能靠全局开关，而要结合业务语义：
- 在写请求响应头或返回体中透传本次写入的 GTID（如
X-Last-Gtid: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:12345） - 读请求携带该 GTID，从库用
SELECT MASTER_POS_WAIT('binlog.000001', 12345, 2)等待指定位置，超时则自动降级主库 - 禁止对同一张表在短时间（如 5 秒）内混合走主/从——容易因 MVCC 快照不一致引发幻读，宁可全走主库
真正难的不是配置参数，而是把“哪个读必须等同步完成”这件事，从中间件下沉到每个业务接口的实现里。很多团队卡在“读写分离框架已封装好”，却忘了框架无法理解“用户刚改密码，下一步查登录态就必须强一致”。
