跳到主要内容

响应式查询优化

这套查询默认是响应式的。数据一变，查询结果就可能跟着变。

真正的问题不是“能不能更新”，而是“每次变更都全量重跑会不会太贵”。

核心思路​

  • 能用 JS 增量合并的，优先增量合并
  • 必须重新计算结构的，才回到 SQL / adapter 层重查

事件来源​

查询管理主要关注这些实体事件：

  • ENTITY_CREATE_EVENT
  • ENTITY_UPDATE_EVENT
  • ENTITY_REMOVE_EVENT

只有真正落库后的事件才会推动查询更新。

为什么很多普通查询可以增量更新​

例如 findAll、count 这类查询，新增一条满足条件的数据，往往只要把结果追加进去或把计数加一，不需要整表重查。

为什么树查询更容易刷新​

树结构不是普通列表。新增、移动、删除一个节点，都可能改变：

  • 某个节点是不是另一个节点的后代
  • 某个节点的祖先链
  • 后代或祖先数量

所以像 findDescendants、findAncestors、countDescendants、countAncestors 这类查询，更容易触发结构性重算。

为什么图查询也更容易刷新​

图结构的路径和邻居同样不是简单数组。新增或删除一条边，可能改变：

  • 最短路径
  • 某节点的可达邻居集合
  • 边权重过滤后的结果

因此图查询不适合以”普通列表追加一条数据”的思路来理解。

核心要点​

  • 查询默认是响应式的
  • 普通列表查询通常比树图查询更容易增量更新
  • 树图查询的结果对结构变化更敏感，重算更正常
  • 业务层不用自己手写“收到事件后手动拼结果”这套逻辑

参考​