Webman的DB类默认不支持读写分离，因其support/database组件为同步阻塞式设计，未内置多连接抽象层，Db::select()等调用始终走配置中的主连接，无法自动按权重、健康状态或延迟阈值路由读请求，事务内强制走主库逻辑也需手动保障。
为什么 Webman 的 DB 类默认不支持读写分离
Webman 使用的 support/database 组件（基于 Medoo 或自研轻量封装）是同步阻塞式设计，Db::table()、Db::select() 等调用默认走同一个主连接。它没有像 Laravel 的 DB::connection('read') 那样的多连接抽象层。
这意味着：你写 Db::select('posts', ['*'], ['id[>]'=>100])，无论什么场景，都发向配置里写的那个 write 连接——哪怕只是查列表页。
- 不做任何干预时，所有读请求都压在主库上，主从延迟大时可能读到旧数据
- 无法按权重、健康状态、延迟阈值自动切读库
- 事务内强制走主库的逻辑需手动保证，否则会报错或数据不一致
手动实现读写分离的三种可行路径
你得自己接管连接选择逻辑，而不是依赖框架“自动识别”。推荐以下方式（按落地成本由低到高）：
-
最简方案（适合中小流量）：在配置中定义两个连接组，
'mysql_write'和'mysql_read'，业务代码里显式调用Db::connection('mysql_read')->select(...)查列表，Db::connection('mysql_write')->insert(...)写新帖 -
中间件拦截方案（推荐）：写一个全局中间件，在请求进入时根据 URL 或方法判断是否只读（如
/topics、/topic/123），然后绑定当前请求的Db实例为读连接；遇到POST /topics或事务操作时再切回写连接 -
代理类封装方案（适合长期维护）：新建
ForumDb类，统一收口所有查询，内部根据 SQL 类型（SELECT/INSERT/UPDATE）、是否在事务中、是否含FOR UPDATE等条件，动态选择连接。注意：不能仅靠 SQL 字符串前缀判断，SELECT COUNT(*) FROM ...是读，但SELECT ... FROM posts FOR UPDATE是写锁，必须走主库
主从延迟下读取脏数据的典型表现与应对
用户发完帖立刻刷新列表页，却看不到自己的新帖——这是主从延迟 + 读库未同步导致的最常见问题。这不是 Webman 的 bug，而是 MySQL 主从复制机制的固有特性。
- 不要依赖“刚写完就去读从库”这种模式；对强一致性要求高的读（如用户刚发的帖、刚改的个人资料），应强制走主库
- 可加一层轻量缓存：写入后立即
$cache->set("user_{$uid}_latest_post", $post, 30)，读时先查缓存，命中则跳过 DB 查询 - 避免在事务中混用读库和写库：Webman 的
Db::beginTransaction()只作用于当前连接实例，跨连接开启事务会导致隐式提交，破坏 ACID
连接池和长连接对读写分离的实际影响
Webman 常驻内存特性让连接复用成为可能，但这反而放大了读写分离配置错误的风险：
- 若你用
pdo_mysql并开启了PDO::ATTR_PERSISTENT，一个连接可能被多个请求复用，而它的 host 是写库还是读库，取决于第一次初始化时的配置——后续请求无法切换 - 正确做法是：每个连接配置单独管理，用连接名区分（如
mysql_write_1、mysql_read_2），并确保连接池大小合理（一般读库连接池 > 写库） - 务必在连接字符串中显式指定
host，不要共用同一份配置数组再改 host 字段——容易因引用传递导致意外覆盖
真正难的不是配两套数据库，而是让每次 SQL 调用都落在正确的连接上，且不出错、不漏切、不误判。这需要你在关键路径上加日志（比如打印当前使用的连接 host），上线前用压测工具验证读写分流比例是否符合预期。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
