ThinkPHP 5.1读写分离需同时满足read_master=true（布尔值）、slave为一维数组、非事务且上一条非写操作，缺一则读请求静默走主库；查询缓存需在对应连接配置中设query_cache=true并配合Redis等驱动，仅对Db::table()链式调用生效。
系统卡顿，90% 的概率不是 PHP 本身慢，而是数据库扛不住了。ThinkPHP 5.1 开启读写分离 + 查询缓存，能立刻缓解主库压力，但配置错一个键，就等于没配——所有读请求仍走主库，且不报错、不提示。
为什么 read_master=true 配了却没用？
TP5.1 不像 TP6 那样依赖 deploy 和 rw_separate，它靠的是 read_master 开关 + 上下文判断，但这个开关极易被忽略或误配：
-
read_master必须是布尔true，写成1、"true"或放在 .env 里都不生效 -
slave配置必须是**一维关联数组**（不是二维），例如：['hostname' => '192.168.1.11', 'username' => 'ro_user', 'password' => 'xxx']；若写成[['hostname' => ...]]，框架会静默跳过从库 - 事务中任何
select()、find()都强制走主库，哪怕read_master=true也无效 - 上一条 SQL 是
INSERT/UPDATE/DELETE时，紧接着的select()默认走主库（避免主从延迟导致“刚写完查不到”）
查询缓存怎么开才真正生效？
TP5.1 的查询缓存（query_cache）默认关闭，且仅对 Db::table()->where()->select() 这类链式调用有效，对原生 Db::query() 或模型方法（如 UserModel::get()）不生效：
- 在
config/database.php的连接配置里加：'query_cache' => true - 必须配合缓存驱动使用，比如 Redis：确保
cache.type设为redis，且redis.host可连通 - 缓存键由 SQL 字符串 MD5 生成，所以带变量的查询（如
where('id', $id)）能正常区分缓存，但拼接字符串的 SQL（如"SELECT * FROM user WHERE id = {$id}"）可能因空格/换行导致重复缓存 - 注意：事务内、含
LOCK、FOR UPDATE的查询，查询缓存自动禁用
哪些操作会悄悄绕过从库和缓存？
ThinkPHP 5.1 不解析 SQL，只看方法签名和执行上下文。以下情况你配得再完美，也白搭：
立即学习“PHP免费学习笔记（深入）”；
- 调用
Db::table('user')->lock(true)->select()→ 强制主库，且不走查询缓存 - 在事务块里执行
Db::startTrans(); Db::table('log')->insert([...]); Db::table('user')->find(1); Db::commit();→ 整个事务内所有读都走主库 - 显式调用
->master()后未重置，后续所有读（包括模型查询）持续锁定主库 -
Db::query('SELECT COUNT(*) FROM user')默认走主库；要走从库+缓存，必须链式写：Db::query('SELECT COUNT(*) FROM user')->useReadConnection()->useQueryCache()
最常被忽略的一点：TP5.1 的读写分离和查询缓存都依赖「连接初始化时机」。如果项目用了多数据库连接（比如同时连 MySQL 和 Oracle），必须确保 read_master 和 query_cache 是写在你要用的那个连接配置里，而不是全局 config 数组顶层——写错层级，等于没写。
