laravel读写分离必须将read/write嵌套在config/database.php的同一mysql连接内，而非新增独立连接；read为从库数组（轮询），write为单主库关联数组，共用配置须在外层声明，sticky=>true可避免写后读不到的主从延迟问题。
必须改 config/database.php 里的 mysql 连接结构，把 read 和 write 嵌套进去，而不是新增两个独立连接；否则所有查询仍走主库，从库压根不会被用到。
read/write 必须嵌套在同一个 connection 下
常见错误是加了 mysql_master 和 mysql_slave 两个连接，然后在模型里手动调用 on('mysql_slave') ——这不算读写分离，只是硬编码切换，事务、连接复用、故障转移全得自己兜底。
-
read是数组，可填多个从库配置（每个是关联数组），Laravel 默认轮询 -
write必须是单个关联数组（哪怕只有一台主库也要写成['host' => '...']） - 共用字段（如
database、username、password、charset）必须提到外层，不能塞进read或write里，否则会被忽略 - 别漏掉
driver，它必须在外层显式声明，否则连接初始化失败
sticky 开关决定“写后立刻可读”是否生效
默认 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::table('users')->where('id', 1)->first()，只要它发生在 DB::transaction() 或 DB::beginTransaction() 之后，就会强制发到主库。这不是配置问题，是 Laravel 保证事务一致性的底层逻辑。
- 事务中混用读/写意图没有意义，框架直接忽略读写分离规则
- 想在事务里查从库？不行。只能把读操作提前到事务外，或接受主库压力
- 用
DB::connection('mysql')->table(...)不会改变这个行为；只有显式指定非mysql连接名（比如mysql_slave）才可能绕过，但那就脱离了 Laravel 的读写分离机制
最易被忽略的点：shared 配置项位置和 sticky 的触发边界。很多人配完发现从库没流量，第一反应是检查网络或权限，其实只是 database 写进了 read 里，或者忘了设 sticky => true。
