ThinkPHP5数据库主从分离需同时配置deploy=>1和rw_separate=>true，仅设deploy=1仅启用多节点解析，不触发读写分离；rw_separate=true才是执行开关，使SELECT走从库、INSERT/UPDATE/DELETE走主库。
ThinkPHP5 的数据库部署模式不是靠“开关”启用的，而是由 deploy 和 rw_separate 两个配置项共同决定是否走主从逻辑 —— 单独设 deploy => 1 不会自动读写分离，必须配合 rw_separate => true 才生效。
deploy=1 是分布式标识，不是主从开关
ThinkPHP5 中 deploy 参数只表示「当前连接是否支持多节点」，取值为 0（集中式）或 1（分布式）。它本身不触发读写行为分发，仅告诉框架：接下来的 hostname、username 等字段可能传入多个值（用逗号分隔）。
常见错误是只改了 'deploy' => 1，但没动 rw_separate，结果所有查询仍打到第一个地址（默认主库），从库完全闲置。
-
deploy => 0：忽略后续的多地址配置，只用hostname第一个值 -
deploy => 1：允许解析逗号分隔的地址列表，但是否读写分离，还得看rw_separate - 若
rw_separate => false，即使deploy => 1，所有操作（含select）仍走第一个地址
rw_separate=true 才真正启用读写分离逻辑
rw_separate 是读写分离的执行开关。设为 true 后，框架会在运行时判断 SQL 类型：INSERT/UPDATE/DELETE 走主库（hostname 第一个地址），SELECT 随机选从库（从第二个开始的地址中轮询或随机）。
立即学习“PHP免费学习笔记（深入）”；
注意：这个判断基于 SQL 关键字，不是方法名。调用 Db::table('user')->select() 会被识别为读；而 Db::table('user')->where('id', 1)->update(['name'=>'a']) 会被识别为写。
- 主库地址必须是
hostname列表的第一个，如'hostname' => '192.168.1.10,192.168.1.11,192.168.1.12' - 从库用户名/密码若与主库不同，需用逗号同步提供：
'username' => 'master,slave1,slave2' - 若从库数量 >1，TP5 默认随机选取，不支持权重或健康检查，故障从库会导致查询失败
hostname 多地址写法与参数合并规则
hostname 是唯一必须用逗号拼接的字段；其他如 database、username、password 可以全写（如 'database' => 'db1,db2,db3'），也可以只写一个值（如 'database' => 'myapp'），框架会自动复用到所有节点。
但要注意：如果某个从库数据库名不同，就必须显式写全，否则会连错库。比如主库叫 myapp_master，从库叫 myapp_slave，那就得写 'database' => 'myapp_master,myapp_slave,myapp_slave'。
- 端口
hostport同理：若统一为3306，可只写'hostport' => '3306'；若从库用了3307，就得写'hostport' => '3306,3307,3307' -
params数组中的 PDO 设置（如PDO::ATTR_PERSISTENT）对所有节点生效，无法按节点单独配置 - 配置项里没出现的字段（如
charset），会全局复用，不存在“主库 utf8、从库 gbk”的混合编码支持
debug 模式下如何确认读写是否真的分离？
开启 'debug' => true 后，TP5 会在日志里记录每次查询使用的连接信息。关键看 SQL 日志前缀：
-
[ DB ] CONNECT:[ UseMaster ] mysql://...→ 写操作，命中主库 -
[ DB ] CONNECT:[ UseSlave ] mysql://...→ 读操作，命中从库 - 如果全是
UseMaster，说明rw_separate没生效，或 SQL 被误判为写（比如带FOR UPDATE的SELECT）
另外，SELECT ... FOR UPDATE 这类语句在 TP5 中仍归类为「写」，会强制走主库 —— 这是设计行为，不是 bug，但容易被忽略。
主从延迟、事务内读一致性、从库只读权限缺失，这些底层问题不会被框架屏蔽，配置完部署模式后，必须用真实业务 SQL 测试读路径是否稳定落到从库，而不是只看配置有没有报错。
