Laravel环境部署数据库读写分离配置：主从同步与连接池优化【详解】

想在生产环境里真正用好 Lara vel 的数据库读写分离，光在 `.env` 里配两个主从地址是远远不够的。真正的核心其实就两件事：一是让框架按规则自动分发读/写请求，二是避免因为主从延迟或者事务逻辑搞出数据不一致的坑。配置本身不算复杂，但细节上一旦走偏，从库基本就白设了。 ### 主从连接必须放在同一个连接名下，而不是拆成两个独立连接 先明确一点：Lara vel 识别读写分离的路由结构只有一种。你得在 `config/database.php` 里，把 `read` 和 `write` 两个子数组嵌套到同一个连接名下，比如 `mysql`。千万别想着建两个独立连接，比如 `mysql_master` 和 `mysql_sla ve` 各管各的，那样框架根本不会自动切换。 配置时有几个硬性要求要注意： - `read` 必须是数组。哪怕你只有一个从库，也要写成 `[['host' => '192.168.1.10']]`，不能偷懒。 - `write` 必须是单元素关联数组，比如 `['host' => '192.168.1.5']`，用索引数组是行不通的。 - 所有共用参数——`database`、`username`、`password`、`charset` 这些——必须提到外层来写。如果顺手塞到 `read` 或 `write` 内部，Lara vel 压根不会认。 - `driver` 也要显式声明在外层，并且保持为 `mysql`。 这个结构有点像“套娃式”的嵌套，但理解之后其实很清晰，关键是不要想当然地按直觉去配置。 ### `sticky` 这个开关，才是防主从延迟的核心保障 默认情况下，`sticky` 是 `false`。这意味着什么？结合一个常见场景就明白了：你在一次请求里刚执行完 `User::create()`，紧接着又调用了 `User::find(1)` 去查新创建的用户。如果此时读请求落到了还没完成同步的从库上，那结果就是查不到——这不是 bug，这是设计上的必然。 把 `sticky` 设为 `true` 之后，行为就变了。只要当前这个请求周期内发生过任何写操作（包括 `insert`、`update`、`sa ve`，甚至 `DB::statement('INSERT')`），后续的所有读操作都会强制走主库。这个标记在事务结束后依然生效，属于框架设计上的一个特征，不是缺陷。不过也要留意，它可能会让一些本来没必要走主库的、非关键的读请求也留在主库上。 说到底，`sticky` 不是用来提升性能的，它是数据一致性的底线机制。生产环境里，建议始终把它打开。 ### 事务和 Eloquent 里的行为陷阱，往往比配置更让人头疼 说实话，很多读写分离的问题其实不是出在配置本身，而是出在大家对 Lara vel 路由逻辑的理解偏差上。 一旦进入 `DB::transaction()` 或者手动调用了 `beginTransaction()`，整个连接上下文就变了。此时所有查询——包括 `DB::table('users')->first()` 这样的读操作——都会统一走 `write` 连接，没有例外。所以不要在事务里做“只是查一下”的假设。 再一个容易忽略的点：Eloquent 模型默认并不走从库。像 `User::all()`、`User::find(1)` 这类查询，默认都是命中的主库。想让它们走读库，得显式调用 `User::on('mysql')->get()`，前提是你已经在这个连接上正确定义了 `read/write`。 此外，`with()` 预加载和 `withTrashed()` 这类查询会重置连接的上下文，有时候会导致意外地切回主库。如果你只是要“查一次配置 + 写一条日志”，最好把查配置的操作提前到事务外面去，别为了省一次连接把它硬塞进事务里，反而得不偿失。 ### 从库的负载均衡，关键是和连接池配合好 多个从库不只是好看的配置。Lara vel 原生支持按权重来轮询分发读请求，但要想真正发挥作用，还得连接池策略跟得上。 做法很简单：在 `read` 数组里为每个从库节点加上 `'weight' => 3` 这样的整数权重。Lara vel 在运行时会根据所有节点的权重总和，按比例随机选取，不需要你额外写代码去控制。 还有个小建议：从库的连接配置里最好把 `'strict' => false` 加上，避免因为 MySQL 版本差异或者 SQL mode 不一致导致连接失败。 连接池层面，可以考虑启用 PDO 的长连接（`PDO::ATTR_PERSISTENT`），或者用 Lara vel Octane 配合 Swoole 的连接池来减少握手开销。最后，验证是否生效的方法也很直接：在 `AppServiceProvider@boot` 里开一下查询日志，然后执行 `DB::table('users')->first()`，检查日志里的 host 地址是不是来自你配置的从库列表。 整体来看，读写分离的配置、`sticky` 的使用、事务内的行为理解、以及从库的负载均衡，这几个环节是环环相扣的。忽视任何一环，都可能让读写分离变成“看起来有用，实际上没用”的摆设。