Yii框架的缓存依赖怎么设置_db和tag依赖实现缓存更新【技巧】

dbdependency 通过每次读缓存前重执行sql并比对标量结果来判断失效，须用聚合函数、显式指定db组件、避免硬编码表名；tagdependency需手动维护tag一致性，推荐带业务前缀的命名；二者可组合使用，但需注意依赖链路与缓存后端兼容性。

缓存依赖里 DbDependency 怎么写才生效

直接说结论：DbDependency 不是“监听数据库变化”，而是每次读缓存前重新执行一次 SQL，对比结果是否变化。如果 SQL 返回值变了，缓存就失效。

常见错误是写了个永远返回固定值的查询，比如 select 1，或者漏了 db 配置导致查默认连接、连错库。

• SQL 必须返回**标量值**（一行一列），推荐用聚合函数，如 SELECT MAX(updated_at) FROM post
• 必须显式指定 db 组件，尤其在多数据库场景下：new DbDependency(['sql' => $sql, 'db' => yii::$app->get('db2')])
• 注意 SQL 中的表名别用硬编码前缀，建议走 Yii::$app->db->tablePrefix 或用 {{%post}} 占位符
• 不要在 SQL 里写 WHERE 动态条件（比如带 :id），因为依赖对象是复用的，参数不会自动刷新

TagDependency 的 tag 名怎么管理不冲突

tag 是字符串标识，Yii 用它做缓存项分组标记。tag 本身不自动关联数据，全靠你手动维护一致性——这也是最容易出问题的地方。

典型翻车现场：更新了文章，只删了 post-123 缓存，却忘了给所有含这篇文章的列表缓存打上 tag:post-123，导致列表没刷新。

• tag 命名建议带业务前缀和粒度，比如 post:123、user:profile:456，避免纯数字或泛化名如 data
• 一个缓存项可以同时依赖多个 tag：new TagDependency(['tags' => ['post:123', 'user:456']])
• 批量失效时，用 Yii::$app->cache->deleteByTag('post:123')，不是 delete()
• 别把 tag 当成“事件总线”——它不触发回调，也不通知其他地方，只是个标记开关

DbDependency 和 TagDependency 能不能一起用

能，而且经常要一起用，但顺序和职责得理清：通常 DbDependency 控制“底层数据是否变”，TagDependency 控制“这个缓存属于哪几组业务逻辑”。两者是 AND 关系，任一失效整个缓存就过期。

举个实际例子：首页推荐文章列表缓存，既要检查最新文章时间戳（DB），又要关联当前用户偏好 tag（比如 rec:user:789），两个都得满足才命中。

• 组合写法：new DependencyChain([new DbDependency([...]), new TagDependency(['tags' => ['rec:user:789']])]) —— 注意 Yii 2.0.14+ 才支持 DependencyChain
• 低版本只能嵌套：把 TagDependency 当主依赖，里面再包一层 DbDependency 作为其 dep 属性（不推荐，可读性差）
• 性能上，每个依赖都会在 get 时触发一次判断，两个依赖 = 至少两次 DB 查询或 tag 检查，高并发下注意压测

缓存更新失败的三个隐蔽原因

不是代码写错，而是环境或配置细节卡住：查起来费时间，但改起来就一行。

• cache 组件没配 keyPrefix，导致不同环境（本地/测试/生产）缓存 key 冲突，删 tag 删到别人头上
• DbDependency 的 SQL 查询用了未索引字段（如 created_at 没建索引），缓存读取变慢甚至超时，被静默降级为无依赖缓存
• 使用文件缓存（FileCache）时，TagDependency 不生效——它只在支持 tag 的缓存后端（如 redis、APC）里起作用，文档里藏得深，很多人踩坑

复杂点从来不在语法，而在依赖链路上谁负责刷新、谁负责标记、谁又悄悄绕过了校验。盯住那几个字符串 tag 和那条 SQL 的执行结果，比看框架源码还管用。