核心性能与特性差异 #

邻接表+递归查询 #

• 优势：原生支持无需额外扩展，数据模型直观（仅需parent_id关联父节点），节点增删改逻辑简单，适配频繁变动树形结构的场景。
• 性能表现：查询深层后代时会遍历路径节点，数据量大、层级极深时性能下滑明显，但给parent_id建立索引后，中小规模树形（数千节点）的查询性能完全够用。
• 示例代码：

  WITH RECURSIVE category_tree AS (
    SELECT id, name, parent_id FROM categories WHERE id = 1 -- 指定根节点ID
    UNION ALL
    SELECT c.id, c.name, c.parent_id FROM categories c
    JOIN category_tree ct ON c.parent_id = ct.id
  )
  SELECT * FROM category_tree;
  

ltree扩展 #

• 优势：专为树形结构设计，节点存储完整路径（如root.child.grandchild），通过路径匹配查询后代/祖先无需递归，深层遍历、大规模树形场景下性能远超递归查询。
• 性能表现：基于GIN/GIST索引实现路径匹配，查询速度极快，适配节点数十万级以上、查询操作远多于写操作的场景。
• 示例代码：

  -- 添加ltree类型列并创建索引
  ALTER TABLE categories ADD COLUMN path ltree;
  CREATE INDEX idx_categories_path ON categories USING GIN(path);
  
  -- 查询节点1的所有后代
  SELECT * FROM categories WHERE path @> '1'::ltree;
  -- 查询节点3的所有祖先
  SELECT * FROM categories WHERE path <@ '1.2.3'::ltree;
  

适用场景总结 #

• 选邻接表+递归查询：

  • 项目规模小，节点数量不多；
  • 节点增删改操作频繁，需要极简的树形关系维护逻辑；
  • 需保持数据库原生兼容性，不想依赖第三方扩展。

• 选ltree：

  • 树形结构层级深、节点数量庞大；
  • 频繁执行节点后代/祖先查询，对性能要求高；
  • 写操作相对较少，可接受路径维护的额外逻辑成本。

关键注意事项 #

• 使用ltree时需手动维护路径（插入子节点时基于父节点路径生成新路径），节点移动时需批量更新子节点路径，逻辑复杂度高于邻接表。
• 邻接表的递归查询必须给parent_id建索引，否则性能会严重恶化：CREATE INDEX idx_categories_parent_id ON categories(parent_id);

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