php 不负责数据库主从复制，仅作为客户端适配；主从复制是数据库层面通过 binlog 同步与 relay log 回放实现的异步日志复制机制，php 需在应用层实现读写分离并应对主从延迟。
PHP 本身不负责数据库主从复制，它只是客户端；主从复制是数据库（如 mysql）层面的机制，PHP 应用通过连接不同实例来适配这一架构。
主从复制的核心原理
主从复制本质是“日志同步 + 回放”：主库（Master）将数据变更记录到二进制日志（binlog），从库（Slave）通过 I/O 线程拉取 binlog 到本地中继日志（relay log），再由 SQL 线程顺序执行其中的事件，从而保持数据一致。
关键点包括：
- binlog 格式影响复制行为（STATEMENT、ROW、MIXED），推荐 ROW 模式以保证精确性
- 复制是异步的，默认不保证实时一致性，存在主从延迟（seconds_behind_master）
- 从库只读（set read_only=1）是常规配置，防止误写破坏复制链路
PHP 如何配合主从架构
PHP 不参与复制过程，但需在应用层做读写分离：写操作（INSERT/UPDATE/delete）发往主库，读操作（select）可路由到从库（或主库）。
立即学习“PHP免费学习笔记（深入）”；
常见做法有：
- 手动控制：业务代码中显式指定数据库连接（如 new pdo($master_dsn) 或 new PDO($slave_dsn)）
- 使用中间件或扩展：如 MySQL router、ProxySQL，对应用透明地分发请求
- 基于框架封装：Laravel 的 DB::connection(‘write’) / DB::connection(‘read’)，ThinkPHP 的 db()->master()->query() 等
注意：强一致性读（如刚写完立刻查）必须走主库，否则可能读到旧数据。
主从延迟与故障应对
网络抖动、大事务、从库负载高都会导致 seconds_behind_master 增大。PHP 应用需有容错意识：
- 对非关键读取容忍延迟，比如列表页、统计类查询
- 对关键读取（如订单支付后查状态）加主库读强制策略，或引入延时判断逻辑
- 监控从库延迟，超阈值时自动降级为全走主库（需配合健康检查与连接池管理）
常见误区提醒
误区一：“PHP 配置了主从就能自动复制”——错误。PHP 只是使用者，复制完全由数据库服务端配置驱动（如 CHANGE MASTER TO、START SLAVE）。
误区二：“读写分离后性能一定提升”——不一定。若读请求本身极少或从库性能不足，反而增加运维复杂度和延迟风险。
误区三：“从库崩溃不影响写入”——基本正确，但若主库也出问题且无容灾设计，整个系统仍不可用；建议搭配高可用方案（如 MHA、Orchestrator 或 MySQL Group Replication）。