闭包表需预先创建nodes和node_ancestors两张表，后者必须含ancestor_id、descendant_id、depth三字段并建索引；触发器在AFTER INSERT/UPDATE/DELETE中自动维护祖先路径，UPDATE/DELETE须成对清理旧数据，否则导致查询错误。
闭包表结构必须先建好，否则触发器无处写入
闭包表（closure table）不是单张表，而是两张：一张主数据表（比如 nodes），一张关系表（比如 node_ancestors），后者存所有祖先-后代对及距离。触发器不负责建表，只负责在 nodes 变更时自动维护 node_ancestors。如果漏建 node_ancestors 或字段不匹配（比如缺 depth 列），触发器执行会直接报错 column "depth" does not exist。
典型建表语句如下：
CREATE TABLE nodes ( id SERIAL PRIMARY KEY, name TEXT, parent_id INTEGER REFERENCES nodes(id) ); <p>CREATE TABLE node_ancestors ( ancestor_id INTEGER NOT NULL REFERENCES nodes(id), descendant_id INTEGER NOT NULL REFERENCES nodes(id), depth INTEGER NOT NULL CHECK (depth >= 0), PRIMARY KEY (ancestor_id, descendant_id) );</p><p>-- 必须加索引，否则 INSERT/DELETE 触发器会变慢 CREATE INDEX idx_node_ancestors_desc ON node_ancestors(descendant_id); CREATE INDEX idx_node_ancestors_anc ON node_ancestors(ancestor_id);
INSERT 触发器要同时插入自身和所有祖先路径
当新节点插入时，它自己是自己的祖先（depth = 0），还要把它的父节点、祖父节点……逐级向上查出来，连同对应 depth 一起写入 node_ancestors。不能只写一层父关系——那不是闭包表，是邻接表冗余。
关键点：
-
BEFORE INSERT不可行：此时NEW.id还没生成（除非显式指定），且无法递归查祖先 - 必须用
AFTER INSERT，并配合WITH RECURSIVE自查祖先链 - 避免在触发器里调用函数查祖先——容易隐式锁升级，直接在触发器体里写递归 CTE 更可控
示例触发器函数片段：
CREATE OR REPLACE FUNCTION sync_node_ancestors_on_insert() RETURNS TRIGGER AS $$ BEGIN -- 自身映射 INSERT INTO node_ancestors (ancestor_id, descendant_id, depth) VALUES (NEW.id, NEW.id, 0); <p>-- 向上递归找所有祖先，并插入（含 depth） WITH RECURSIVE ancestors AS ( SELECT parent_id AS id, 1 AS depth FROM nodes WHERE id = NEW.parent_id UNION ALL SELECT n.parent_id, a.depth + 1 FROM nodes n INNER JOIN ancestors a ON n.id = a.id WHERE n.parent_id IS NOT NULL ) INSERT INTO node_ancestors (ancestor_id, descendant_id, depth) SELECT id, NEW.id, depth FROM ancestors WHERE id IS NOT NULL;</p><p>RETURN NEW; END; $$ LANGUAGE plpgsql;
UPDATE 和 DELETE 触发器必须成对清理旧路径
仅处理 INSERT 是不够的。如果改了 parent_id，旧的祖先路径仍留在 node_ancestors 里，查询就会出错；如果删节点，不删它作为祖先的所有记录（即它下面整个子树的映射），会导致脏数据。
常见错误现象：
-
UPDATE后查子树多出重复节点：旧ancestor_id没删干净 -
DELETE后SELECT * FROM node_ancestors WHERE descendant_id = ?还能查到已删节点：触发器没删以该节点为descendant_id的行 - 用
TRUNCATE nodes清空表：触发器不触发，node_ancestors全残留
正确做法：
-
UPDATE触发器：先DELETE所有以OLD.id为descendant_id的行（清除旧路径），再按新parent_id插入新路径（逻辑同 INSERT） -
DELETE触发器：必须DELETE FROM node_ancestors WHERE ancestor_id = OLD.id OR descendant_id = OLD.id——前者删它作为祖先的路径，后者删它作为后代的路径
触发器性能瓶颈往往卡在深度递归和索引缺失
闭包表的优势是查询快，代价是写入重。一棵 10 层深的树，插入一个叶子节点，触发器可能要往 node_ancestors 插入 10+ 行；若平均分支因子是 5，删除根节点可能触发上千行删除。这些操作都在主事务内完成，直接影响业务响应时间。
实操建议：
- 确保
nodes.parent_id有索引：CREATE INDEX ON nodes(parent_id)，否则递归 CTE 查祖先极慢 - 避免在触发器里做复杂计算或调用外部函数（如
dblink、http_get），它们会阻塞事务 - 如果树深度常超 20 层或变更频繁（>100 QPS），别硬扛——改用应用层异步更新闭包表，或换 ltree 扩展（对固定路径场景更轻量）
- 测试时用
EXPLAIN ANALYZE跑触发器内 CTE，确认没走 seq scan
真正容易被忽略的是：闭包表同步只解决“层级关系快查”，不解决“路径内容变更传播”。比如节点名字改了，node_ancestors 里不会自动更新关联的 name 字段——那得靠业务逻辑或额外视图拼接，触发器管不了这个。
