PHP读写分离需主从复制就绪且应用层精准路由：主库必须开启binlog、server-id唯一、创建REPLICATION SLAVE用户，从库SHOW SLAVE STATUS中IO和SQL线程均为Yes且Seconds_Behind_Master稳定；Laravel的read/write配置仅对Eloquent和DB门面生效，事务、Raw SQL、显式连接均绕过路由，sticky=true可缓解主从延迟，多从库需健康检查与合理负载均衡。
PHP 读写分离不是靠改 PHP 配置文件就能生效的，它依赖数据库层的主从复制已就绪，且应用层明确区分读/写连接路由。没配好主从同步，光在 PHP 里切连接，只会读到过期或空数据。
MySQL 主从复制必须先验证通了再动 PHP
很多 PHP 开发者一上来就改 database.php 或写路由逻辑，结果查不到新数据、SELECT 返回空、甚至报 Lost connection to MySQL server——根本原因是主从压根没同步成功。
- 主库必须开启
log-bin，设置server-id = 1，并创建带REPLICATION SLAVE权限的用户 - 从库执行
CHANGE MASTER TO后，务必运行SHOW SLAVE STATUS\G，确认Slave_IO_Running和Slave_SQL_Running都是Yes，且Seconds_Behind_Master稳定为0（或极小值） - 别信
Slave_IO_Running: Yes就万事大吉——如果Master_Host显示为空，或Seconds_Behind_Master持续增长，说明 relay log 没真正拉下来 - 常见断连原因：主库防火墙没放开 3306、从库时间不同步、
max_allowed_packet不一致、主库 binlog 被自动清理（expire_logs_days太小）
Laravel 的 'read'/'write' 配置不是全自动的
Laravel 的数据库配置支持 read 和 write 数组，但它只对 Eloquent 查询构建器和 DB:: 门面生效；原生 PDO 操作、Raw SQL、事务块内、或用了 DB::connection('mysql') 显式指定连接名，都会绕过这个路由机制。
- 配置示例中
'sticky' => true是关键：它让一次请求内后续读操作复用刚写过的主库连接，避免主从延迟导致“写完立刻查不到” - 如果用了
DB::transaction()，整个事务强制走write连接，哪怕里面只有SELECT——这是正确行为，不能靠配置关掉 - 从库连接池要独立配置
pool参数，否则高并发下所有读请求挤在同一个从库连接上，反而比单库还慢 - 不要把从库地址写成
127.0.0.1：本地回环无法体现真实网络延迟，上线后才发现读请求超时
自定义读写路由时，SQL 类型判断不能只靠正则
手动用 preg_match('/^(INSERT|UPDATE|DELETE)/i', $sql) 匹配写操作，看似简单，实际漏掉大量边界情况。
立即学习“PHP免费学习笔记（深入）”；
-
REPLACE INTO、INSERT ... ON DUPLICATE KEY UPDATE、TRUNCATE TABLE都是写操作，但不匹配上述正则 -
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE本质是读+写锁，必须走主库，否则会报错或死锁 - 存储过程调用
CALL proc_name()无法静态判断读写类型，应统一走主库，或在过程内显式标注 - 更稳妥的做法是封装一个
DB::rw()方法，由业务层显式声明意图：DB::rw('write')->table(...)->update(...)，而不是让框架猜
从库负载均衡不是加个数组就行
多个从库时，Laravel 默认轮询（round-robin），但生产环境不能只看“平均分配”。
- 用
DB::connection('mysql.read.0')这种硬编码索引的方式，等于放弃负载均衡能力 - 权重配置需结合真实硬件：一台 32C64G 的从库和一台 8C16G 的，不能按 1:1 分流量；Laravel 不原生支持权重，得自己扩展
ReadPreference类 - 必须加入健康检查：某个从库
SHOW SLAVE STATUS异常时，应临时剔除其连接，否则请求持续打过去，全量超时 - 注意 DNS 缓存：如果从库地址用域名，PHP 的
PDO默认不刷新 DNS，IP 变更后连接仍发往旧地址，要用options => [PDO::ATTR_PERSISTENT => false]配合短连接规避
主从延迟、连接泄漏、权限粒度、监控盲区——这些才是读写分离落地时真正卡住进度的地方。配完 read/write 数组只是第一步，后面每台从库的 Seconds_Behind_Master 值、每个连接的 wait_timeout 设置、每次部署后是否重跑 SHOW SLAVE STATUS，才决定它到底能不能扛住流量。
