ThinkPHP数据库配置详解：主从数据库配置与读写分离实操【方法】

ThinkPHP读写分离配置完成后，如果发现查询语句仍然全部落在主库，通常不是代码逻辑出了毛病，而是database.php中两个关键开关没有正确配置，或者数组结构没有按框架要求对齐。更具体点说，就是“deploy”这个参数必须设置为整型1，“rw_separate”必须是布尔值true，两者缺一不可，而且配置块的结构必须从旧式的单值写法切换到TP6所要求的master/sla ve数组格式。

开头先说一个核心判断：大多数读写分离“不生效”的问题，本质上都不是框架的bug，而是配置结构的“静默失效”——键名少打一个下划线，或者数组嵌套少了一层，框架不会报错，但读操作会默认回落主库。下面直接拆开讲最主流的两种配置方式，以及几种即使配置正确也会强制走主库的特殊场景。

TP6标准配置：启用开关+结构化主从数组

其实操作本身并不复杂，就是在config/database.php的connections.mysql块内补上两个布尔开关。但这两个开关属于“一个都不能少”，漏掉任何一个，整个读写分离配置都会变成一纸空文。

第一步，打开config/database.php，找到connections['mysql']这个配置块。如果你用的是其他连接名，比如'pgsql'，那就对准对应的键名来改。

第二步，确认这个块里存在且仅存在以下两行：【'deploy' => 1】 和 【'rw_separate' => true】。这里有一个很容易踩的坑：'deploy'必须是整数1，写成true或字符串"1"都不行；'rw_separate'必须是布尔true，写成1或"true"会直接失效。类型问题在这种底层配置里非常敏感。

第三步，删掉这个配置块里所有旧式的单值配置项，比如DB_HOST、DB_NAME这类写法。它们和TP6的结构化模式有冲突，混在一起会导致框架读取配置时出现混乱。

第四步，定义'default'为主库的完整配置数组，包含type、hostname、database、username、password这些基本字段。然后添加一个'sla ve'键，这个键的值必须是二维数组，每个从库子数组里必须包含hostname、database、username、password四项。少了任何一项，框架会直接抛出一个InvalidArgumentException，提示"Database config sla ve is invalid"，错误信息相当直接，不给你半点模糊空间。

TP5兼容配置：逗号分隔地址+开关启用

这套方案适用于老项目做平滑迁移，业务代码基本不用动，但有个前提：所有从库的连接参数必须高度一致，否则配置会变得很难维护。

实现方法也不复杂。首先在config.php或database.php中设置'DB_DEPLOY_TYPE' => 1和'DB_RW_SEPARATE' => true，这两个开关的作用和TP6版是一样的。

关键区别在于数据库地址的写法。需要把主库和从库的IP用英文逗号拼接成一个字符串，赋值给'DB_HOST'。例如：'DB_HOST' => '192.168.1.10,192.168.1.11,192.168.1.12'。框架会默认把第一个地址当作主库，后面的地址按顺序轮询使用。

与之对应的，'DB_NAME'、'DB_USER'和'DB_PWD'这些字段也必须按相同的顺序对齐填写。如果所有从库的库名相同，'DB_NAME'可以简写成单个值，但用户名和密码必须严格对齐，否则第二个从库会用第一个用户的密码去连接，结果可想而知——连接失败。

强制走主库的三种典型场景

即使前面的配置全部正确，有些场景下读操作也会被强制路由回主库。这不是bug，恰恰是框架内置的安全保护策略。

第一种，带锁查询。比如Db::table('user')->lock(true)->find()这样的操作，无论写得多标准，都会直接走主库。原因很简单：从库的锁状态可能和主库不一致，带锁查询放在从库上毫无意义。

第二种，事务内的读操作。只要开启了事务，比如用Db::transaction包裹的函数，里面所有的select语句都会强制路由到主库。这同样是出于一致性的考虑——事务内的数据变更在主库上还没提交，从库根本看不到。

第三种，手动锁定主库。调用->master(true)方法或者全局的Db::master()之后，后续所有的查询都会被固定到主库，直到你显式调用Db::sla ve()或者在请求结束后自动恢复。这个功能在写后立读的场景下特别实用，比如刚保存完一篇文章，立刻查询确认，显然不能等从库同步。