在PDO中动态切换读库和写库，核心是分离主从连接实例：写操作必须调用getWritePdo()获取主库连接，读操作优先通过getReadPdo()随机选取健康从库；事务、写后即读、行锁查询及DDL等强一致性场景必须强制走主库，且禁止复用同一PDO实例混用读写。
怎么在 PDO 中动态切换读库和写库
PHP 里做读写分离，核心不是换框架，而是控制 PDO 实例的来源——写操作必须走主库连接，读操作优先走从库连接。不能靠注释或约定来区分，得在代码执行时就决定用哪个连接。
常见错误是把“读”和“写”混在同一个 PDO 实例里，或者用全局单例硬编码一个连接，导致所有查询都打到主库，从库完全闲置。
- 用工厂函数封装连接逻辑：
getWritePdo()返回主库实例，getReadPdo()随机返回一个健康从库实例（可加简单心跳检测） - 避免在 DAO 类里直接 new PDO；改用依赖注入或服务容器传入
$pdo实例，让调用方决定传读库还是写库 - 主从库配置需独立：比如
DB_HOST_WRITE和DB_HOST_READS（后者是数组），别共用一个DB_HOST
哪些查询该走读库？哪些必须走写库？
不是所有 SELECT 都能读从库，也不是所有 INSERT/UPDATE/DELETE 后立刻要查就得切回主库——关键看是否涉及刚写入的数据一致性。
- 明确写后即读场景（如注册后立刻查用户信息、下单后查订单状态）：必须用写库连接，否则可能查不到或查到旧数据
- 普通列表页、统计汇总、缓存穿透兜底查询：可用读库，但要注意从库延迟。若业务容忍秒级延迟，可加
/* slave */注释标记（部分中间件识别） -
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE必须走写库，从库不支持行锁 - 事务内所有语句统一走写库，哪怕第一条是
SELECT—— 因为事务上下文只存在于主库
如何避免 ORM 自动路由出错（以 Laravel Eloquent 为例）
Laravel 默认的 read/write 配置只对模型基础操作生效，一旦你手写 DB::select()、用 DB::transaction() 或调用 toSql() 后自己执行，就绕过了路由逻辑。
立即学习“PHP免费学习笔记（深入）”；
- 禁用
DB::connection('read')这类硬编码连接名，改用DB::connection()（默认读）和DB::connection('write')（显式写） - 模型中重写
getConnectionName()是高危操作，容易被 scope 或关联查询覆盖；更稳妥的是在 Repository 层统一控制连接 - 使用
DB::table('users')->useWritePdo()->insert(...)这类显式声明（需自定义扩展），比依赖自动识别可靠 - 注意
DB::statement()执行 DDL（如ALTER TABLE）必须走写库，且不能在从库连接上调用，否则报错SQLSTATE[HY000]: General error: 1788 Statement is not safe to log in statement format.
从库延迟导致数据不一致，代码里怎么兜底
主从延迟无法彻底消除，代码层面只能做分级应对：非关键读允许延迟，关键读主动等或降级。
- 对强一致性要求的读，加
sleep(0.1)后重试（最多 2 次）不是好办法，应改用主库连接 - 可设计轻量级延迟探测：比如写入后立即查主库的
SHOW MASTER STATUS和从库的SHOW SLAVE STATUS，对比Seconds_Behind_Master，超阈值（如 > 1s）则切主库 - 更实用的是业务层埋点：写操作后生成唯一
$trace_id，读操作带上它，中间件检测到该 trace 刚发生过写，则强制走主库 - 不要在应用层做复杂的 GTID 等待逻辑——MySQL 5.7+ 的
SELECT MASTER_POS_WAIT()需要主从开启 binlog 格式为ROW，且会阻塞，线上慎用
最常被忽略的一点：连接池或长连接复用时，PDO 实例的状态（比如是否在事务中、是否设置了 SET NAMES）会污染后续请求。务必确保每次请求获取的是干净连接，或在使用前后显式 $pdo->setAttribute(PDO::ATTR_AUTOCOMMIT, true) 重置。
