用户反馈系统很卡顿？ThinkPHP 5.1 数据库读写分离与查询缓存开启【体验】

系统卡顿，十有八九不是PHP本身慢，而是数据库先扛不住了。ThinkPHP 5.1 开启读写分离加上查询缓存，确实能立刻缓解主库的压力。但问题在于，配置错一个键，就等于白忙活——所有读请求依然会走主库，而且不报错、不提示。关键点在于，必须同时满足几个硬性条件才能让读写分离真正生效，缺一不可。

先说 read_master=true 这个配置。TP5.1 不像 TP6 那样依赖 deploy 和 rw_separate，它靠的是 read_master 开关加上上下文判断，但这个开关特别容易被忽略或误配。首先，read_master 必须是布尔值 true，写成 1、"true" 或放在 .env 文件里都不生效。其次，sla ve 配置必须是**一维关联数组**，比如 ['hostname' => '192.168.1.11', 'username' => 'ro_user', 'password' => 'xxx']；如果写成 [['hostname' => ...]] 这种二维数组，框架会静默跳过从库，根本不报错。另外，事务中的任何 select() 或 find() 都会强制走主库，哪怕 read_master=true 也无效。最后，上一条 SQL 如果是 INSERT/UPDATE/DELETE，紧接着的 select() 默认也走主库——这是为了避免主从延迟导致“刚写完查不到”的问题。

再来说查询缓存。TP5.1 的查询缓存默认关闭，而且只对 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，它只看方法签名和执行上下文。以下情况，配置得再完美也白搭：

• 调用 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 数组顶层——写错层级，等于没写。