ThinkPHP中如何追踪数据库的主从读写分离路由_读写分离调试技巧-ThinkPHP-PHP中文网

thinkphp读写分离需显式配置'read'数组且非空，db::master()仅对当次链式调用生效，getlastsql()不反映实际执行库，强制主库查询需用db::master()整链调用或事务包裹。

thinkphp中如何追踪数据库的主从读写分离路由_读写分离调试技巧

ThinkPHP 的读写分离不是默认开启的，哪怕你配了多个数据库节点，read 节点也不会自动被调用。关键看 database.php 里是否显式声明了 'read' 键，且值为数组（不能是空数组或 null）。

常见错误现象：Db::table('user')->select() 始终走主库，SHOW PROCESSLIST 或慢日志里看不到从库连接。

检查配置中是否有类似 'read' => ['host' => '192.168.1.10']，且该数组至少含一个有效节点
'read' => [] 或 'read' => null 等价于关闭读分离，所有 SELECT 都会 fallback 到 write（主库）
如果用的是集群模式（'type' => 'mysql_cluster'），需额外确认 'deploy' => 1 和 'rw_separate' => true 同时存在

Db::master() 是手动指定连接的快捷方式，但它只在「当前查询」生效，不改变后续链式调用的路由逻辑。很多人误以为加了它就能“锁定主库”，结果发现 ->where()->find() 还是走了从库 —— 因为 find() 内部又重新做了路由判断。

使用场景：适合调试单条 SQL 是否被正确分发，或需要绕过读写分离执行强一致性查询（如刚插入就立刻查）。

getLastSql() 只返回最后生成的 SQL 字符串，不反映真实执行位置。ThinkPHP 在执行前才根据当前操作类型（SELECT / INSERT）、是否在事务、是否手动指定 master() 等条件决定连接对象 —— 这个决策过程完全不体现在 SQL 字符串里。

性能影响：如果你依赖 getLastSql() 日志判断读写分离效果，会严重误判。真正有效的调试方式是抓包或看数据库连接来源 IP。

推荐方法：在从库执行 SHOW PROCESSLIST，过滤客户端 IP，确认是否有来自应用服务器的 SELECT 连接
更准的方式：在 think\db\Connection 的 connect() 方法里加日志，打印 $config['hostname'] 和 $isRead 标志
注意：开启 'debug' => true 后，think/db/Connection.php 的 getRealSql() 会记录实际连接信息，但需配合日志驱动解析

可以，但不是靠改配置，而是靠「打破读写分离的触发条件」。ThinkPHP 对 SELECT 路由的判断优先级是：事务 > 手动指定 master > 主从配置 > 默认读库。所以最稳妥的方式是临时进事务，哪怕不写数据。

容易踩的坑：有人试图用 Db::table('user')->useMaster(true)->select()，但这个方法并不存在 —— ThinkPHP 没提供全局开关，只有 master() 实例级控制。

安全做法：Db::transaction(function () { return Db::table('user')->where('id', 1)->find(); });
轻量做法：Db::master()->table('user')->where('id', 1)->find()（必须整条链路都用该实例）
警告：不要在高并发场景滥用 master()，会把从库流量压力全部压回主库，可能引发雪崩

读写分离的边界很细，比如带 FOR UPDATE 的 SELECT 会被识别为写操作，自动走主库；而 SELECT COUNT(*) 这类聚合查询，在无事务时一定走从库 —— 这些隐式规则比配置本身更容易让人掉坑里。