PHP不直接监控主从延迟，而是通过定时任务调用SHOW SLAVE STATUS解析Seconds_Behind_Master并缓存至Redis，PHP读取缓存值判断延迟；超阈值时在连接抽象层干预路由，强制关键读走主库，并需结合Slave_IO_Running、Slave_SQL_Running状态综合判定。
PHP本身不直接监控主从延迟，真正起作用的是对MySQL SHOW SLAVE STATUS 的调用结果解析，再结合业务逻辑做判断和响应。硬上“全量校验”或“每秒查一次Seconds_Behind_Master”反而容易拖垮从库或掩盖真实问题。
怎么安全地获取从库延迟值
不能在每次读请求前都执行 SHOW SLAVE STATUS —— 它需要 REPLICATION CLIENT 权限，且频繁查询会加重从库负载，尤其当有多个从库时。
- 用独立的定时任务（如 cron）每 5–10 秒查一次，把结果缓存到
Redis，键名建议带从库标识，例如slave_delay:192.168.1.10 - PHP 脚本里只读缓存：
$delay = $redis->get('slave_delay:192.168.1.10');，避免直连从库 - 若必须直查（如调试），确保连接的是专用监控账号，且语句加超时：
mysqli_query($conn, "SHOW SLAVE STATUS", MYSQLI_ASYNC)不推荐；更稳妥是设mysqli_options($conn, MYSQLI_OPT_CONNECT_TIMEOUT, 1) - 注意：MySQL 8.0.22+ 中
Seconds_Behind_Master在某些并行复制场景下可能为NULL或不准，需同时检查SQL_Delay和Slave_SQL_Running_State
延迟超阈值时 PHP 怎么自动切读流量
不是简单“换一个PDO对象”，而是要在连接抽象层让路由决策可干预。Laravel 的 DB::connection()->with(['read' => 'master']) 是表层写法，底层仍依赖连接池是否支持 sticky 模式。
- 自研 DAO 层应在初始化时注入延迟感知器：
new SlaveAwareReader($redis, $thresholdMs = 500) - 关键读方法如
findOrder($id)内部调用$this->reader->mustReadFromMaster()，而非靠 SQL 类型判断 - 不要在模型里硬编码
DB::connection('mysql_master')，容易漏掉关联查询、事务内嵌套读等边界情况 - 如果用了 Swoole 或 RoadRunner，注意连接复用会导致延迟状态过期，需在协程上下文里缓存本次请求生效的延迟值
为什么光看 Seconds_Behind_Master 不够
Seconds_Behind_Master 只反映 IO 线程拉取日志的延迟，不等于数据已重放完成。常见误判场景：
立即学习“PHP免费学习笔记（深入）”；
- 主库刚写入一条大事务（比如批量更新百万行），
Seconds_Behind_Master可能还是 0，但 SQL 线程正卡在重放中 —— 此时查不到新数据 - 从库启用了
slave_parallel_workers > 0，而Seconds_Behind_Master在部分版本中无法准确反映实际 lag - 网络抖动导致 IO 线程断连，
Seconds_Behind_Master显示NULL，但Slave_IO_Running已是No，此时应视为严重故障而非“延迟高” - 更可靠的指标组合是：
Slave_IO_Running === Yes&&Slave_SQL_Running === Yes&&Seconds_Behind_Master < 500
最易被忽略的一点：延迟监控不是为了“报警”，而是为了给读路由提供可信依据。一旦发现某从库 Seconds_Behind_Master 持续 > 1s，就该把它从负载均衡列表里临时剔除，而不是等它崩掉才反应过来。
