在 Laravel 项目中配置数据库读写分离时，你是否遇到过这样的困惑：明明在配置文件中为 read 项设置了多个从库，甚至还精心分配了权重，但实际运行时，查询请求却总是不按“套路”出牌，要么全跑到主库，要么从库的流量分配完全不符合预期？
问题的根源，其实不在于配置语法，而在于 Laravel 框架底层的连接管理逻辑。默认情况下，Laravel 并不原生支持“按权重随机选择从库”这种高级功能，它只提供了两种基础模式：要么固定回退（fallback），要么手动指定连接名。如果你只是简单地把从库列表写成数组，那么所谓的“权重”字段根本不会被框架读取，自然也就无法实现按比例分流。
为什么 read 和 write 连接会走错库？
首先需要明确一点：配置了多个 read 主机，并不意味着你的读操作就一定会自动、智能地分配到从库。这里有几个关键机制在起作用：
- 读写上下文判定：像
DB::select()或User::query()->get()这类读操作，只有在当前数据库会话中没有活跃的写事务时，Laravel 才会尝试为其分配read连接。 - “粘性”连接的影响：一旦前面执行过
DB::transaction()或模型的save()等写操作，后续所有的数据库操作（包括读）都会被“粘”在主连接上，除非你显式地使用on('read')来指定。 - 默认的负载均衡策略：即使你的
read配置是一个包含多个主机的数组，Laravel 默认采用的也是简单的“轮询”策略，它完全无视你手动添加的weight字段。所以，感觉流量分配“不听话”，其实是框架的默认行为。
怎么让从库真正按权重分流？
既然原生不支持，要实现按权重的分流，就必须自己动手，接管 read 连接的选择逻辑。一个相对轻量且优雅的方案，是利用配置项支持闭包的特性，动态地返回连接名。
具体操作路径如下：
- 改造配置结构：在
config/database.php的数据库配置（例如mysql）中，将read键的值从一个静态数组，改为一个返回连接名的function()闭包。 - 实现权重算法：在闭包内部，使用
mt_rand()结合权重配置进行概率抽样，最终返回选中的具体连接名（如'mysql-read-1'）。 - 定义独立连接：你需要将每个权重不同的从库，在
connections数组下定义为独立的连接配置（如mysql-read-1,mysql-read-2），确保它们拥有相同的database、username等核心参数，但host指向不同的从库服务器。 - 谨慎处理
sticky：这个配置项至关重要。务必将其设为false，才能解除读写操作的强制绑定，让读操作有机会分离到从库。如果设为true，则会强制同一请求内的所有数据库操作都使用主库连接。
下面是一个核心的配置示例片段：
'mysql' => [
'read' => function () {
// 定义连接名与权重的映射
$weights = ['mysql-read-1' => 70, 'mysql-read-2' => 30];
$rand = mt_rand(1, 100);
$sum = 0;
foreach ($weights as $name => $weight) {
$sum += $weight;
if ($rand <= $sum) return $name;
}
// 兜底返回
return 'mysql-read-1';
},
'write' => [...], // 写连接配置
'sticky' => false, // 必须为false
],
DB::connection('mysql') 为什么还是连主库？
这个问题很常见，也容易让人误解。当你直接调用 DB::connection('mysql') 时，你获取的是名为“mysql”的这个逻辑连接组。Laravel 在首次解析这个连接组时，会根据上下文（通常是默认的写上下文）缓存一个具体的 PDO 连接实例。如果此时没有触发读操作判定，它自然就缓存了主库的连接。
要理清这里面的门道，可以关注以下几点：
- 显式指定与自动分发：使用
DB::connection('mysql-read-1')可以绕过自动分发，直连特定从库，但这也就失去了权重分流的意义。我们通常希望的是通过标准读方法（如模型查询）自动触发分发。 - 确保干净的读上下文：要让自动读分发生效，需确保查询前没有开启事务，也没有执行过任何写操作。同时，注意检查中间件，有些权限验证中间件会提前执行用户查询，意外地“粘住”了主库连接。
- 诊断连接状态：如果怀疑连接错了库，一个实用的调试方法是打印当前 PDO 实例的连接状态：
DB::connection()->getPdo()->getAttribute(PDO::ATTR_CONNECTION_STATUS)，这能帮你确认实际连接的数据库主机。
从库延迟导致数据不一致怎么办？
实现了权重分流，另一个无法回避的挑战就是主从延迟。分流本身不解决延迟问题，反而可能让不一致的情况随机出现——你无法预知哪一次读请求会命中那个延迟较高的从库。
面对这个问题，业务上需要接受“最终一致性”的现实，技术上则可以进行分级管控：
- 强一致性读：对于刚写入就必须立刻读取的场景（如支付成功页），应显式使用
DB::connection('mysql-write')或链式调用->useWritePdo()方法，强制走主库。 - 弱一致性读：对于列表页、统计报表等非关键读操作，可以放心交给权重分流，容忍秒级的数据延迟。
- 避免依赖从库特定变量：切勿在从库连接上依赖
last_insert_id或@@binlog_gtid_executed这类变量，它们在从库上可能不可靠或无意义。 - 动态权重调整：监控各从库的
Seconds_Behind_Master（主从延迟秒数）。当某个从库延迟超过阈值时，可以通过配合服务发现或配置中心热重载，临时将其从权重池中剔除或降低其权重。
说到底，权重分流是一种流量分配的技术手段，而非数据一致性方案。要真正保证强一致性，关键在于收口业务层的读路由逻辑，由开发者明确指定特定查询的读写路径，而不是完全寄希望于框架去自动判断每一条 SQL 该去哪台机器。
