路径枚举用varchar字段存储祖先id链（如'1/5/12/47'），依赖前缀索引和like匹配实现高效祖先/子孙查询；闭包表则用独立关联表（ancestor_id、descendant_id、depth）预存所有层级关系，支持精确深度过滤与直接join，但写操作复杂、一致性维护成本高。
路径枚举（path）和闭包表（closure table）不是“替代递归CTE的银弹”，而是为特定 JOIN 场景设计的预计算结构——用空间换查询简单性，但写操作成本高、一致性难保。
路径枚举字段怎么建、怎么用 JOIN
路径枚举依赖一个字符串字段（如 path），存类似 '1/5/12/47' 的祖先 ID 链。它本身不参与父子关联，而是靠字符串匹配支撑 JOIN：
- 查某个节点的所有祖先：外层查
t.id = 47，JOIN 时用ON t2.path LIKE CONCAT(t1.path, '/%')，再加WHERE t2.id IN (SELECT id FROM category WHERE path LIKE '1/5/%')就错——LIKE不能直接用于 JOIN 条件右侧的子查询结果 - 必须让路径字段带索引：
INDEX idx_path (path)，否则LIKE '1/5/%'会全表扫描 - 插入新节点时，
path值必须由应用层拼接，不能靠数据库自增生成；若父节点path被误改，整条路径就断了，且无自动校验 - MySQL 8.0+ 支持函数索引，可用
CREATE INDEX idx_path_len ON category ((CHAR_LENGTH(path)))加速深度过滤
闭包表的 JOIN 写法和常见漏掉的字段
闭包表是独立的关联表（如 category_closure），至少含三列：ancestor_id、descendant_id、depth。JOIN 时容易忽略 depth 的语义：
- 查某分类下所有子孙（含自身）：
JOIN category_closure cc ON c.id = cc.ancestor_id，再JOIN category c2 ON c2.id = cc.descendant_id—— 没加WHERE cc.depth >= 0会导致自身被漏掉（如果设计时约定 depth=0 表示自身） - 查“直接子分类”必须加
WHERE cc.depth = 1，只靠ON条件无法区分层级 - 闭包表必须有联合唯一索引：
UNIQUE KEY uk_anc_desc (ancestor_id, descendant_id)，否则重复插入同一对关系会破坏树结构 - 新增节点时，要批量插入多行：自身→自身（depth=0）、自身→每个现有子孙（depth += 1）、每个现有祖先→自身（depth += 1）——少插任何一类，树就残缺
路径枚举 vs 闭包表：JOIN 性能差异在哪
两者都避免递归，但 JOIN 效率取决于数据分布和过滤时机：
- 路径枚举在
WHERE中用path LIKE '1/5/%'过滤，走的是前缀索引，快；但若想查“所有 depth=3 的节点”，就得SUBSTRING_INDEX拆字段，无法走索引 - 闭包表查固定深度极快（
WHERE depth = 2直接命中索引），但查“某个路径下的全部子孙”需先查出所有ancestor_id，再反向 JOIN，中间结果集可能巨大 - 两者都不适合频繁移动节点的场景：路径枚举要批量 UPDATE 所有后代的
path字段；闭包表要删+重新 INSERT 数百上千行记录 - 如果业务只要“查某节点的直属子项”，普通
parent_id索引 + 单层 JOIN 更轻量，别硬套这两种模型
真正麻烦的不是怎么写 JOIN，而是谁来保证 path 字段里没多出一个空格、category_closure 里有没有漏掉 depth=0 的自引用行——这些细节不出错时风平浪静，一出就是跨层级的数据错乱，还很难回溯。
