本质是MySQL主从复制延迟，非TP5.1框架问题；需从强制主库读、拆分大事务、启用并行复制、心跳表精准测延时四方面解决。
TP5.1 使用主从分离时，从库延迟导致“刚写完就查不到”，本质不是框架问题，而是 MySQL 主从复制机制的固有特性。TP5.1 的读写分离只是把读请求发给从库，它不解决数据同步延迟。要真正解决问题，得从同步机制、事务控制、读路由策略三方面入手。
一、关键读操作必须强制走主库
对强一致性场景（如注册后立即查用户信息、下单后立刻查订单状态），不能依赖从库。TP5.1 支持手动指定数据库连接：
- 用
Db::connect('master')->table('user')->where('id', $id)->find()显式调用主库 - 在模型中重写
db()方法，根据上下文判断是否 force master（例如检查是否有刚插入的 ID 或 session 标记） - 避免在控制器里写 “先 insert，紧接着 select * from xxx where id = last_insert_id()” 并发到从库——这种写法在主从架构下天然不可靠
二、拆分大事务，减少单次同步压力
TP5.1 默认事务提交是全量的。如果业务中有批量导入、日终结算等操作，一个事务更新几万行，会直接卡住从库 SQL 线程：
- 改用循环 + 分批提交：每 500～1000 行
$model->saveAll($batch)后手动Db::commit() - 避免在事务中调用外部 HTTP 接口或 sleep()，这些会拉长 T1→T3 时间
- DDL 操作（如加字段）不要放在业务代码里执行，应单独窗口期用 pt-online-schema-change 工具操作
三、启用并行复制并验证是否生效
TP5.1 不干预底层复制，但你要确保 MySQL 从库已正确开启逻辑时钟并行：
- 登录从库执行：
STOP SLAVE; SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; SET GLOBAL slave_parallel_workers = 4; START SLAVE; - 执行
SHOW PROCESSLIST，确认出现多个Slave_worker线程，且状态不是长期卡在 Waiting for an event from Coordinator - 注意：仅当主库也开启了
binlog_transaction_dependency_tracking = WRITESET，并行效果才最佳；否则同库多表仍可能串行
四、用心跳表替代 Seconds_Behind_Master 做真实延迟判断
Seconds_Behind_Master 在并行复制下经常显示为 0，但实际某张表还没更新完。建议加一张轻量心跳表：
- 主库定时（如每秒）执行：
INSERT INTO heartbeat (ts) VALUES (NOW(6)) ON DUPLICATE KEY UPDATE ts = NOW(6); - 从库查：
SELECT UNIX_TIMESTAMP(6) - UNIX_TIMESTAMP(ts) FROM heartbeat;—— 这个差值才是业务可感知的真实延迟 - TP5.1 可封装一个
Heartbeat::getDelay()方法，在关键读前判断：若延迟 > 500ms，自动切主库
