主从复制+读写分离是最常用方案，写走主库、读分发从库以降负载提吞吐；需监控复制延迟、强一致读直连主库、代码层可控路由、严控从库写权限、多从库轮询与健康检查。
用主从复制 + 读写分离是最常用、最有效的方案，核心是让写操作只走主库，读操作尽量分发到从库，从而降低主库负载、提升整体吞吐。
主从架构要稳，复制延迟得盯住
主库写入后，数据靠 binlog 同步到从库，但网络、从库负载高、大事务都可能导致延迟。延迟太高时，用户刚提交订单就查不到，体验会断层。
建议做法：
- 监控 Seconds_Behind_Master（MySQL）或 GTID 延迟，设置告警阈值（如 > 3 秒）
- 对强一致性读（如订单详情、账户余额），直接走主库，不走从库
- 业务层加简单标记，比如 URL 参数 read=master 或接口头带 X-Read-Preference: master，动态路由
读写分离不能全靠中间件，代码层要可控
虽然有 MyCat、ShardingSphere 等中间件，但 php 项目中更推荐在框架或 DB 封装层做轻量路由——逻辑清晰、调试方便、升级灵活。
立即学习“PHP免费学习笔记（深入）”；
典型实现思路：
- 统一 DB 类或 pdo 封装里识别 sql 类型：以 select 开头且不含 for UPDATE 的走从库；其余（INSERT/UPDATE/delete/SELECT … FOR UPDATE）走主库
- 支持手动指定连接：$db->select(…)->on(‘slave’) 或 $db->transaction()->on(‘master’)
- 避免 ORM 自动 join 多表时误发到从库——复杂查询建议显式指定连接池实例
从库不是“只读保险箱”，得防意外写入
mysql 从库默认 read_only=ON，但 SUPER 权限用户仍可写。一旦应用配置错误或运维误操作，从库被写脏，同步就会中断甚至丢数据。
安全加固建议：
- 从库账号权限严格限制：只授予 SELECT, SHOW VIEW, REPLICATION SLAVE
- 数据库配置增加 super_read_only=ON（MySQL 5.7+），彻底禁止 SUPER 用户写入
- 部署前用脚本检查所有从库的 read_only 和 super_read_only 状态
流量再均衡：从库也得轮询和健康检查
多个从库不是摆设。如果所有读请求都打到同一台，那只是把压力从主库挪到了某台从库。
实用策略：
- 用随机或权重轮询选从库，避免单点过载；可结合 CPU、连接数等指标做简易负载感知
- 每次连接前 ping 一下从库，失败则剔除并降权，10 秒后自动重试加入（避免雪崩）
- 慢查询日志定期分析，发现某从库响应明显变慢，及时下线排查（可能是索引缺失或锁表）
不复杂但容易忽略：读写分离不是一配了之，关键在一致性边界把控和链路可观测性。主库扛写、从库分读，配合延迟治理和权限卡控，才能真正把压力摊开。