php应用实现读写分离需在代码层控制：写操作强制走主库，读操作默认走从库但留强一致性读接口；统一db类解析sql类型路由，pdo须维护独立主从连接池，事务必须绑定主库。
怎么让 PHP 应用自动走主库写、从库读
PHP 本身不内置读写分离逻辑，必须靠你在代码里控制连接路由。核心是：写操作（INSERT、UPDATE、delete、REPLACE）强制走主库连接；读操作（select）默认走从库连接——但得留后门，比如某些强一致性读必须指定主库。
常见错误是把“读写分离”当成数据库中间件功能，结果在 PHP 层没做任何判断，所有查询都随机打到某个节点，主从延迟时直接读到旧数据。
- 用一个统一的数据库访问类（比如封装
PDO或mysqli）接管所有连接创建和语句分发 - 在执行前解析 SQL：用
preg_match('/^s*(SELECT|WITH)/i', $sql)判断是否为读，其余一律视为写 - 提供显式指定连接的接口，例如
$db->select(...)->useMaster()->execute()，避免“我以为是读，其实是写”的陷阱 - 不要依赖注释（如
/*+ USE_MASTER */）做路由，PHP 层无法可靠提取，且容易被 ORM 或框架自动过滤
MySQL 主从延迟下，哪些 SELECT 必须走主库
不是所有 SELECT 都能放心扔给从库。主从延迟几秒很常见，一旦业务逻辑存在“写完立刻读”，就会出问题——比如用户注册后跳转到个人页，查不到刚插入的记录。
典型强一致性读场景包括：
立即学习“PHP免费学习笔记（深入）”；
- 刚执行过
INSERT/UPDATE的同一事务内后续SELECT - 用户登录后立即查自己的权限、配置、未读消息数
- 订单支付成功后立刻查订单状态（哪怕只查
WHERE id = ?） - 任何带
for UPDATE或LOCK IN SHARE MODE的SELECT（必须主库，否则锁无效）
别指望 SELECT ... FROM table WHERE id = ? 就一定安全——如果主库还没同步到从库，这条语句在从库返回空，业务就断了。
用 PDO 实现双连接池要注意什么
用 PDO 做读写分离时，不能共用一个 PDO 实例，必须维护至少两个独立连接：一个指向主库（$pdoMaster），一个或多个指向从库（$pdoSlaves 数组）。常见坑是连接复用混乱或事务穿透。
- 主库连接开启
PDO::ATTR_EMULATE_PREPARES = false，避免预处理语句在从库报错（从库可能禁用PREPARE） - 从库连接关闭
PDO::ATTR_ERRMODE的异常模式，改用PDO::ERRMODE_SILENT，防止某台从库挂掉导致整个读失败（可 fallback 或重试） - 事务中禁止切换连接：一旦
beginTransaction()，后续所有操作必须走主库，且不能在事务中调用读方法自动切到从库 - 注意
PDO::ATTR_PERSISTENT持久连接在读写分离下可能复用错连接——持久连接名需区分主/从，例如"mysql:host=master;..."和"mysql:host=slave1;..."
为什么 laravel 的 DB::transaction() 默认不走主库
Laravel 的 DB::transaction() 看似聪明，实际默认仍会尝试从连接池取连接，而如果你没显式绑定事务到主库，它可能从从库连接开始事务——这在 MySQL 从库上会直接报错：Error 1792 (HY000): Cannot execute statement in a READ ONLY transaction。
根本原因是 Laravel 的连接选择发生在事务开启前，且不感知 SQL 类型。修复方式很简单：
- 写事务必须显式指定连接：
DB::connection('mysql-master')->transaction(...) - 或者在配置里把
'read' => []的从库列表设为空，让读写都落到主库（仅调试用） - 不要依赖
DB::unprepared()或原生查询绕过路由，它不改变连接归属，仍可能打到从库
最易被忽略的是：ORM 的 save()、update() 等方法内部也走写连接，但关联查询（如 $user->posts）默认走读连接——这种混合访问在主从延迟时极难排查。