laravel读写分离生效的前提是config/database.php中mysql连接必须嵌套read/write结构并启用sticky=>true，否则所有查询仍走主库；read须为数组、write须为单元素关联数组，共用配置须在外层，事务内及eloquent模型默认操作均强制走主库。
直接说结论：Laravel 高并发读场景下，读写分离不是“开了就能扛住流量”，关键在 config/database.php 里把 mysql 连接正确重构为嵌套 read/write 结构，并配好 sticky => true；否则从库压根不会被用到，所有查询仍走主库。
config/database.php 必须嵌套 read/write，不能只加两个独立连接
很多人以为加个 mysql_slave 连接、再在模型里写 User::on('mysql_slave')->get() 就算读写分离——不是。这只是手动切换，事务、连接复用、故障转移全得自己兜底，也不触发 Laravel 原生的路由逻辑。
Laravel 的自动路由只认一个连接名（比如 mysql）下同时存在 read 和 write 键。必须这样写：
'mysql' => [
'driver' => 'mysql',
'database' => env('DB_DATABASE'),
'username' => env('DB_USERNAME'),
'password' => env('DB_PASSWORD'),
'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',
'prefix' => '',
'strict' => false,
'read' => [
['host' => env('DB_READ_HOST_1')],
['host' => env('DB_READ_HOST_2'), 'weight' => 2],
],
'write' => [
'host' => env('DB_WRITE_HOST'),
],
'sticky' => true,
],
-
read必须是数组，哪怕只有一个从库也要写成[['host' => '...']] -
write必须是关联数组（不是索引数组），且只能有一个元素：['host' => '...']，不能是['192.168.1.5'] - 共用字段（
database、username、password、charset等）必须提到外层，写在read或write内部会被忽略 -
driver必须显式声明在外层，否则连接初始化失败
sticky => true 不是可选项，是防主从延迟的刚需开关
默认 sticky => false，开了读写分离却没开这个，用户刚提交表单就查不到自己刚填的数据——这不是 bug，是预期行为：SELECT 落到了还没同步完的从库上。
PHP中文网提供Laravel 13.2.0版本下载，Laravel框架 是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。
设为 true 后，只要当前请求中执行过 insert()、update()、save()、delete() 或 DB::statement('INSERT ...')，后续所有 Model::find()、DB::table()->get() 都强制走主库。
- 该行为仅限当前请求生命周期（HTTP 或 CLI 单次运行），不跨请求、不依赖 session
- 事务回滚后，
sticky标记仍保留——这是设计，不是 bug，但可能误伤后续读请求 - 队列任务中
sticky无效（无实时读需求，也跨进程）
事务内所有查询强制走主库，无法绕过
这是最常被踩的坑：DB::transaction() 或 DB::beginTransaction() 一开启，后续所有查询——包括 DB::table('users')->where('id', 1)->first()——一律发到 write 连接，无视是否是 SELECT。
- 试图在事务里调
DB::connection('mysql')->table('logs')->get()依然走主库 - 想查从库？不行。只能把读操作提前到事务外，比如先查用户权限再开启事务
- 如果业务只是“查配置 + 写日志”，就把查配置放到事务前，别为了省一次连接硬塞进去
-
withTrashed()、with()预加载会重置连接，可能意外切回主库
Eloquent 默认不走读库，纯 DB::table() 才触发自动路由
User::all()、User::find(1) 这些看似是读操作，但 Eloquent 模型默认把整个连接当成可写连接处理，所以仍走主库。
- 最稳妥的是在模型里加
protected $connection = 'mysql_read';，并单独定义一个mysql_read连接——但这绕过了 Laravel 原生读写路由，得自己管故障转移 - 更推荐用
User::on('mysql')->where()->get()，前提是你的mysql连接已正确定义read/write -
DB::select()这类纯读语句会走从库，但DB::statement()即使是SELECT也会走主库（因框架按方法名判断语义）
真正容易被忽略的点是：共用配置写错位置、read 写成对象而非数组、sticky 没开、事务里硬塞读逻辑——这些都会让从库完全空转，高并发时主库照旧被打爆。
