Odoo 树形结构为什么有时查得特别快：_parent_store、child_of 和层级查询机制讲透

先说结论

在 Odoo 里，只要模型开始有树形层级，比如：

• 分类
• 部门
• 区域
• 上下级结构

你迟早会遇到：

• child_of
• _parent_store

最实用的理解是：

child_of 在表达“查出这个节点下面整棵子树”，而 _parent_store 往往是在帮系统把这种层级查询做得更稳、更快。

为什么这个主题总让人一开始看不懂

因为表面上你看到的只是：

• 一条记录有 parent_id

于是很自然会觉得：

• 那查子节点不就是一层层找下去吗？

逻辑上没错。

但一旦数据量变大、层级变深、查询频繁，系统就不能总靠“每次临时往下递归”去撑。

这也是 _parent_store 这类机制真正有价值的地方。

child_of 真正在表达什么

它不是在问“直接孩子是谁”，而更像在问：

这条记录往下整棵子树里有哪些对象。

所以它天然适合：

• 树形分类下的全量子分类查询
• 某部门下面所有子部门
• 某节点下整棵组织树

也就是说，它表达的是层级闭包，而不是一层直连关系。

_parent_store 更像什么

它更像：

系统为了高效处理层级关系，而额外准备的一层树形索引语义。

所以它的意义不在“多一个字段看着专业”，而在：

• 让层级查询不用每次都从头递归
• 让 child_of / parent_of 这类查询更可控

这类机制的价值，通常是在树一深、数据一多时才真正体现出来。

为什么树形查询不只是“parent_id 连一下”这么简单

因为层级问题真正难的地方不是一条边，而是整棵树。

例如：

• 这个分类下面所有子分类的文章
• 这个部门下面所有成员与子部门
• 这个区域下面全部仓库范围

这些都不只是“找儿子”，而是“找整棵后代”。

所以系统需要的不是单条外键关系，而是更适合层级检索的语义支持。

为什么性能问题常在树形结构里被放大

因为如果每次都现场递归整棵树：

• 查询会更重
• 逻辑会更绕
• 深层节点尤其容易拖慢

所以你看到 _parent_store 这类设计时，最好别把它看成“额外复杂度”，而要把它看成：

• 层级查询规模上来后的必要支撑。

实战里最容易踩的 5 个坑

1. 把 child_of 理解成“只查直接下级”

语义会看错。

2. 以为树形模型只要有 parent_id 就够了

大数据量时会暴露问题。

3. 不理解 _parent_store 的性能价值

容易误删或误绕开它。

4. 层级对象查询异常时只看单条 parent_id

会漏掉整棵树语义。

5. 在树很深的场景里还按平面对象思维写 domain

性能和结果都可能出问题。

一句话记忆法

把它记成一句话：

child_of 关注的是整棵子树，而 _parent_store 是为了让这类层级查询在真实数据规模下更稳定、更高效。

理解这一句，树形模型就不会再显得那么黑箱。