针对你在Cosmos DB里要限制子对象层级深度、避免逐层查询父项的低效问题，我整理了几个实用的方案，从最优到适配已有系统的都有：

这是最直接高效的做法，不用再做任何递归或多层查询。思路很简单：

• 给每个对象新增一个depth字段，根对象的depth设为0
• 当创建子对象时，先查询父对象的depth值，新对象的depth就是父对象的depth + 1
• 同时你可以直接判断这个新深度是否超过了业务允许的最大值（比如限制最多3层，就检查父depth +1 <=3）

示例文档：

• 根对象：{"name": "Root", "clientId": "1ea87515-63d2-41b8-b327-5a179394bd4c", "parentId": null, "depth": 0}
• 一级子对象：{"name": "childgroup", "clientId": "1ea87515-63d2-41b8-b327-5a179394bd4c", "parentId": "9a6d3b39-3143-492f-b729-417a721640c9", "depth": 1}

优势：

• 查询深度完全是O(1)，直接读取字段就行
• 写入时只需要一次简单的父对象查询，开销极小
• 后续任何需要按层级过滤、统计的场景，都能直接用depth字段快速实现

注意点：
如果你的业务存在“移动节点到其他父节点下”的操作，需要递归更新该节点下所有子对象的depth值。如果这种操作很少发生，这个方案几乎完美；如果频繁移动节点，可以结合下面的方案2。

如果你的系统已经上线，没办法修改文档结构，Cosmos DB支持的**递归CTE（公共表表达式）**可以帮你一次性查询出从目标父节点到根节点的层级，不用逐层遍历。

比如，假设你的容器叫groups，查询指定parentId对应的层级深度的SQL语句如下：

WITH RECURSIVE GroupHierarchy AS (
    -- 起始节点：用户传入的父对象
    SELECT c.id, c.parentId, 0 AS depth
    FROM c
    WHERE c.id = @targetParentId -- 替换为用户创建新对象时传入的parentId
    UNION ALL
    -- 递归向上遍历父节点，直到根节点（parentId为null）
    SELECT p.id, p.parentId, gh.depth + 1 AS depth
    FROM GroupHierarchy gh
    JOIN p IN groups
    WHERE p.id = gh.parentId
)
-- 获取从目标父节点到根的总层级，加1就是新对象的层级
SELECT MAX(depth) + 1 AS newObjectDepth
FROM GroupHierarchy

如果用户传入的是根节点的parentId（即null），你可以直接返回1作为新对象的深度。

优势：

• 不需要修改现有文档结构，适合已上线系统
• 一次查询就能得到结果，比逐层查询高效得多，Cosmos DB会优化递归查询的执行计划

注意点：

• 确保parentId字段已经创建了索引，否则递归查询的性能会打折扣
• 如果你的层级限制很高（比如超过10层），递归查询的性能会比方案1差一些，但依然远好于逐层查询

如果你的业务除了限制深度，还需要获取完整的层级路径（比如Root/ChildGroup/GrandChild），可以在文档中维护一个path字段，同时从路径中提取深度：

• 根对象：{"name": "Root", "clientId": "...", "parentId": null, "path": "/Root"}
• 一级子对象：{"name": "childgroup", "clientId": "...", "parentId": "...", "path": "/Root/childgroup"}

深度可以通过拆分path的斜杠数量计算（比如/Root/childgroup拆分后有3个元素，深度就是1），不过更稳妥的还是同时维护depth字段，避免每次计算的开销。

这个方案的额外好处是可以快速查询整个层级链的对象，比如用STARTSWITH(c.path, "/Root/")就能找出所有属于Root下的子对象。

如果业务允许修改文档结构，**方案1（维护depth字段）**是最优解，性能最高、实现最简单；如果不能修改现有文档，**方案2（递归CTE查询）**是半高效的替代方案，完美解决逐层查询的低效问题。

内容的提问来源于stack exchange，提问作者Clumpsypenguin