Laravel 5.5 原生支持读写分离，但必须将 read 和 write 嵌套在同一 mysql 连接配置内，而非新增独立连接；read 为从库数组（支持轮询与权重），write 为单主库关联数组，共用配置须置于外层，sticky=>true 可避免主从延迟导致的写后读不到问题。
直接说结论：Laravel 5.5 原生支持读写分离，但必须把 read 和 write 嵌套在同一个 mysql 连接配置里，而不是新增两个独立连接；否则所有查询都走主库，从库压根不会被用到。
config/database.php 的 read/write 必须嵌套在同一连接下
这是最常被踩的坑。很多人加了 mysql_master 和 mysql_slave 两个连接，然后在模型里调 on('mysql_slave')——这不算读写分离，只是手动切换，事务、连接复用、故障转移全得自己兜底。
-
read必须是数组，哪怕只有一个从库也要写成'read' => [['host' => '192.168.1.10']]，不能是'read' => ['host' => '...'] -
write必须是单个关联数组，如'write' => ['host' => '192.168.1.20']，不能是数组套数组或纯字符串 -
database、username、password、charset等共用配置必须提到外层，写在read或write内部会被忽略 - 别漏掉
'driver' => 'mysql'，它必须在外层显式声明，否则连接初始化失败
sticky => true 是防主从延迟的关键开关
默认 sticky => false，开了读写分离却没开 sticky，用户刚提交表单就查不到自己刚填的数据，不是 bug，是预期行为——因为 SELECT 落到了还没同步完的从库上。
- 设为
true后，只要当前请求中执行过insert()、update()、save()、delete()或DB::statement('INSERT ...')，后续所有Model::find()、DB::table()->get()都强制走主库 - 该标记仅限当前 HTTP 请求生命周期，不跨请求、不依赖 session/cache
- 队列任务里不用开
sticky：它是独立进程，且通常不需要「写后立刻读」 - 事务里写了又回滚，
sticky标记仍保留——这是 Laravel 的设计，不是 bug，但业务上可能误伤后续读
事务内所有查询强制走主库，无法绕过
这是另一个高频误判点。只要进了 DB::transaction() 或 DB::beginTransaction()，后续所有查询——包括 DB::table('users')->where('id', 1)->first()——都会无视是否是 SELECT，一律发到 write 连接。
- 试图在事务里调
on('mysql::read')会直接抛出Cannot execute queries while other uncommitted transactions are active - 如果只是“先查再写”，且查的数据不参与事务逻辑（比如查配置、查用户权限），就把
select提到事务外 - 别为了省一次连接硬塞进事务，反而让从库完全空转
-
Eloquent默认不走读库，User::all()、User::find(1)这些看似是读操作，但模型默认把整个连接当成可写连接处理，所以仍走主库
多从库轮询与权重配置靠 read 数组结构自动生效
Laravel 5.5 对 read 数组里的多个从库节点默认采用轮询（round-robin）策略，无需额外代码。若需按权重分配，可在每个从库配置中加 weight 键。
- 例如：
'read' => [['host' => '192.168.1.10', 'weight' => 3], ['host' => '192.168.1.11', 'weight' => 1]]，总权重为 4，前者被选中的概率是 75% - 权重值必须为正整数，且至少有一个大于 0
- 每个从库可带独立的
username、password、port，但database等共享项仍须放外层 - 从库建议设
'strict' => false，避免因 MySQL 版本或 SQL mode 差异报错
真正容易被忽略的是 shared 配置项位置 和 sticky 的触发边界：配完发现从库没流量，第一反应常是查网络或权限，其实只是把 database 写进了 read 里，或者忘了设 sticky => true。
