Laravel读写分离必须在config/database.php的connections.mysql中显式配置read/write子数组，read可多从库轮询，write仅一个主库；需设'sticky'=>true保证写后立即可读，否则主从延迟导致脏读。
主从配置写在 config/database.php 的 connections 里
不是新建文件，也不是改 .env 单行配置就能生效。Laravel 的读写分离依赖连接池级别的路由逻辑，必须在连接定义中显式声明 read 和 write 子数组。
常见错误是只配了多个连接（比如 mysql_master、mysql_slave），但没把它们收进一个逻辑连接的 read/write 结构里，结果查询全走默认连接，从库根本不会被用到。
-
connections.mysql是你实际要用的连接名（比如DB::connection('mysql')） -
read下可写多个从库配置，Laravel 会自动轮询；write只能有一个，且必须和read中任一节点不重复 - 每个子连接里的
host、database、username等字段不能省略，即使和主库一样也要单独写一遍
'mysql' => [
'read' => [
'host' => ['192.168.1.10', '192.168.1.11'],
'database' => 'myapp',
'username' => 'slave_user',
'password' => 'xxx',
],
'write' => [
'host' => '192.168.1.5',
'database' => 'myapp',
'username' => 'master_user',
'password' => 'xxx',
],
'driver' => 'mysql',
'sticky' => true,
],
sticky 开关决定“写后立刻可读”是否生效
关闭 sticky 时，一次请求中执行了 insert，紧接着 select 可能落到从库，而从库还没同步完——这是主从延迟导致的脏读。开启后，只要本次请求中发生过写操作，后续所有读都会强制走主库。
这不是性能优化项，而是数据一致性兜底机制。很多团队开了读写分离却没开 sticky，结果用户刚提交表单就查不到自己刚填的数据，还以为系统卡了。
- 默认值是
false，必须显式设为true才生效 - 只对当前请求生命周期有效，不影响其他请求
- 如果业务能接受几秒延迟（比如后台报表），可以关掉来压测从库吞吐
手动指定读/写连接需调用 DB::connection() 而非模型方法
模型的 where、get 默认走配置里定义的逻辑连接（如 mysql），它内部已按读写分离规则分发。但如果你写了原生 SQL 或想绕过自动路由，就得手动选连接。
常见误区是以为 User::on('mysql_slave')->get() 这样能强制走从库——其实 on() 指定的是整个连接名，而 mysql_slave 并不是一个合法连接名（它只是 mysql.read 的一部分）。
- 要强制读从库：用
DB::connection('mysql')->table('users')->select(...)，然后靠配置里的read自动分发 - 要强制写主库：同上，
DB::connection('mysql')->table('logs')->insert(...) - 真需要跳过读写逻辑？直接建一个独立连接（如
mysql_force_master），但得自己维护事务和配置
验证从库是否真被调用：看日志或数据库进程列表
光看配置不等于生效。Laravel 不报错，但从库没流量，问题往往出在 DNS 解析失败、防火墙拦截、或 MySQL 用户没授权给从库 IP。
最简单的验证方式不是改代码，而是打开查询日志，或者登录各数据库服务器执行 SHOW PROCESSLIST，观察请求来源 IP 是否匹配预期。
- 在
config/database.php的连接配置里加'options' => [PDO::ATTR_EMULATE_PREPARES => true]有助于捕获预处理异常 - 如果从库只有一台且连不上，Laravel 默认会静默降级到主库读（取决于 PDO 驱动行为），你以为分流成功了，其实全是主库扛着
- 多从库场景下，Laravel 不做健康检查，挂掉一台会导致轮询失败，建议配合中间件或自定义连接工厂做探活
配置本身不复杂，难的是主从延迟、权限隔离、连接池复用这几块容易被忽略。尤其是 sticky 和从库可用性，上线前不压测+抓包，大概率出问题。
