分类树在商品类目、内容栏目、地区和组织架构等场景中频繁出现。很多团队一开始会采用邻接表，给每行记录加一个 parent_id，再借助 WITH RECURSIVE 递归展开。这个方案在小数据量下完全够用，但层级变深、树形变复杂后，递归 SQL 的可读性、维护成本和性能都会面临压力。PostgreSQL 提供了一种轻量扩展 ltree，能把分类节点的位置编码为路径值，让上下级判断变成路径匹配，从而省去大量递归逻辑。

ltree 的核心在于用一个点分隔的字符串表示树中的位置，例如 Top.Science.Physics 代表从 Top 到 Science 再到 Physics 的完整路径。查询某个节点的所有后代，本质上是对路径做前缀包含判断；查询某个节点的祖先，则是判断当前路径是否包含在更短路径的集合中。理解这个模型后，分类树的新增、移动、删除和检索都可以围绕 path 列展开。

一、ltree 解决什么问题

邻接表是层级数据最直观的存储方式，但它把关系拆散到了行与行之间。想要拿某个节点的所有后代，就必须递归地在 parent_id 上反复连接，或者使用 WITH RECURSIVE 构建临时结果集。递归 CTE 本身并不难，但一旦业务需要同时过滤深度、统计子树、排序兄弟节点，SQL 会迅速膨胀。不同开发人员写出的递归查询也容易在终止条件、循环路径、去重逻辑上产生分歧。

ltree 采用物化路径思路，把层级关系预先编码到一条列中。以分类 Top.Science.Physics 为例，路径本身已经说明 Physics 的父级是 Top.Science，祖先包含 Top。PostgreSQL 的 ltree 类型不仅存储这段路径，还提供了 <@ 和 @> 等操作符来判定包含方向。比如 path <@ 'Top.Science' 可以判断 path 是否属于 Top.Science 的后代，path @> 'Top.Science.Physics' 可以判断 path 是否为其祖先。配合 GIST 索引，这类包含判断可以不逐行扫描完成。

当然，ltree 并不是要替代所有树形数据设计。它更适合层级相对稳定、读多写少、层级不会超长的分类树。对于变更非常频繁、需要保留复杂边属性或多父节点的场景，仍要结合闭包表或独立邻接表来设计。理解边界，才能用好 ltree。

二、安装扩展与表结构设计

ltree 是 PostgreSQL 的官方扩展，安装成本很低。拥有数据库创建权限的用户直接执行创建扩展语句即可。扩展安装后，ltree 类型和相关函数、操作符、索引支持都会进入当前数据库中。

CREATE EXTENSION IF NOT EXISTS ltree;

分类表通常包含主键、分类名称、父级路径。保留 parent_id 也有助于回溯或做额外约束，但使用 ltree 后，path 列是核心。path 列直接声明为 ltree 类型，写入时使用字符串形式，也可以用 text2ltree 显式转换。

CREATE TABLE categories (
    id bigserial PRIMARY KEY,
    name text NOT NULL,
    path ltree NOT NULL
);

建立索引时，GIST 索引可以覆盖 <@、@>、~、? 等 ltree 操作符，是树形查询的首选。B-tree 索引则适合对 path 做等值比较、排序和范围扫描。两类索引并不互斥，但需要根据查询模式取舍。

CREATE INDEX categories_path_gist_idx ON categories USING GIST (path);

如果只需要按 path 排序展示树结构，B-tree 索引更轻量；如果经常做包含判断、后代展开、祖先追溯，GIST 索引收益更大。对于大多数分类树场景，后者的频率通常更高，因此优先创建 GIST 索引是常见做法。

三、常见树操作：新增、查询、移动与删除

新增节点非常简单，只需要把父节点的 path 作为前缀，拼上新节点名称。例如在 Top.Science 下新增 Physics，可以直接插入完整路径。这种写法比先查询父节点 id 再写 parent_id 更直观。

INSERT INTO categories (name, path)
VALUES
    ('Top', 'Top'),
    ('Science', 'Top.Science'),
    ('Physics', 'Top.Science.Physics'),
    ('Chemistry', 'Top.Science.Chemistry');

查询某个节点的全部后代，用包含操作符 <@ 即可。比如查询 Top.Science 下所有分类，SQL 如下。它会命中 GIST 索引，避免全表扫描。

SELECT id, name, path
FROM categories
WHERE path <@ 'Top.Science'
ORDER BY path;

反过来，想查询某个节点的所有祖先，可以使用 @> 操作符。例如找出 Physics 所在链路上的所有父级分类。

SELECT id, name, path
FROM categories
WHERE path @> 'Top.Science.Physics'
ORDER BY nlevel(path);

如果需要只取直接子节点，不能直接用 <@，因为它会包含更深层的后代。可以结合 lquery 的星号表达式来限制深度：'Top.Science.*{1}' 表示路径必须比 Top.Science 深一层。也可以使用 nlevel(path) = nlevel('Top.Science') + 1 配合 <@ 来过滤。

SELECT id, name, path
FROM categories
WHERE path ~ 'Top.Science.*{1}'::lquery
ORDER BY path;

移动分类子树是分类系统中比较棘手的操作。由于 ltree 把完整路径存在每行里，移动一个父节点时，它的所有后代路径都要跟着更新。可以利用路径前缀替换实现：把旧前缀 Old.Tech 替换为新前缀 New.Tech，仅更新受影响的记录。

UPDATE categories
SET path = text2ltree(replace(ltree2text(path), 'Old.Tech', 'New.Tech'))
WHERE path <@ 'Old.Tech';

这里先通过 ltree2text 把路径转成文本，再用 replace 替换字符串前缀，最后通过 text2ltree 转回 ltree 类型。WHERE 条件限制只更新旧分支下的行，防止无关数据被误改。移动大型子树时，该 UPDATE 会锁住对应索引区间，生产环境建议放在低峰期或拆分批次执行。

删除分支同样依赖包含判断。删除 Top.Science 及其全部后代时，只需一个 DELETE 语句。

DELETE FROM categories
WHERE path <@ 'Top.Science';

从上述操作可以看出，ltree 让树的增删改查都简化为路径包含和前缀替换，不再需要递归。但移动和删除都需要格外注意 WHERE 条件的边界，误操作影响范围较大，必要时应先使用事务或备份表验证。

四、索引选择与性能调优

GIST 索引是 ltree 性能的关键。它支持多种操作符，尤其是包含操作符 <@ 和 @>，可以显著缩小扫描范围。很多开发者在开启 ltree 后没有创建 GIST 索引，导致查询仍走全表扫描，数据量上去后性能问题很明显。可以用 EXPLAIN 确认执行计划。

EXPLAIN
SELECT id, name, path
FROM categories
WHERE path <@ 'Top.Science';

如果计划中出现 Index Scan using categories_path_gist_idx，说明索引生效。如果出现 Seq Scan，则需要检查索引是否创建、查询条件的类型是否匹配、统计信息是否过期。ltree 类型与字符串常量比较时通常会自动推断，但某些复杂表达式需要显式转换。

B-tree 索引在某些场景仍然有价值。比如前端经常需要按 path 字典序排列分类，B-tree 可以提供有序扫描；如果只做 path 等值查找，B-tree 也比 GIST 更紧凑。但对于 <@、@>、~ 这类操作，B-tree 无法有效加速，因此分类树核心查询应优先依赖 GIST。

写入性能方面，GIST 索引维护成本高于 B-tree。对于极高频写入、秒级大量变动的树，ltree 的整条路径更新和索引更新可能成为瓶颈。此时可以考虑把分类树拆成基础树和扩展属性，或者降低写入频率、改为异步批量刷新。分类树本身通常读取远多于写入，权衡后 ltree 依然有优势。

五、ltree 与递归 CTE、闭包表的边界

递归 CTE 是处理邻接表的通用方式，它不需要引入扩展，适合轻量递归、深度有限、查询模式简单的场景。但递归 CTE 在深树、子树统计、多次包含判断中往往需要反复扫描，SQL 也更容易变得复杂。ltree 的路径包含操作把这类查询转化为索引友好的布尔判断，可读性和性能表现更稳定。

物化路径其实就是 ltree 的简化版。如果用普通 text 字段存储路径，也能实现部分包含判断，但不得不自己处理分隔符、逃逸、索引和操作符。ltree 的价值在于内部已经定义好这些语义，并提供类型安全和索引支持，避免重复造轮子。闭包表则存储所有祖先与后代的关系对，能表达更复杂的层级操作，但维护成本高，任意新增或移动节点都要重算大量关系行。ltree 的维护量明显更低，代价是路径长度和标签长度有上限，树不能过深。

如果一个分类树可能出现一个节点属于多个父节点、任意两个节点之间存在多条关系、或者需要在边上挂载权重和属性，那么 ltree 不适合，因为它假设一棵严格的单父树。此时闭包表或带边表的设计更合适。反过来，如果分类树是稳定单父结构，层级在几十层以内，节点数量即使达到百万级，ltree 也能通过路径索引提供较好的查询体验。

总体来看，PostgreSQL 的 ltree 为分类树提供了一种简洁而高效的实现方式。它把树结构保存为自解释的路径值，用内置操作符完成祖先、后代和兄弟节点判断，配合 GIST 索引解决多数层级查询问题。但它不是银弹，需要理解路径限制和写放大成本。实际项目中，可以把 ltree 作为分类树的主查询路径，保留 parent_id 作为冗余，既兼顾易用性，也为未来迁移留有余地。