邻接表是关系型数据库中表示树形结构最常用方式，但查询整棵树、祖先/后代等操作低效；优化需减少递归次数、建parent_id索引、引入level/path冗余字段，深度过大或高频层级查询时应换闭包表或物化路径。
邻接表（Adjacency List）是关系型数据库中表示树形或层级结构最常用的方式：每个节点记录其直接父节点的 ID。虽然结构简单、易于维护，但查询整棵树、某节点的祖先/后代、层级深度等操作天然低效。优化核心在于减少递归查询次数、避免全表扫描、合理使用索引和必要时引入冗余信息。
基础查询：获取子树与路径
标准 SQL 不原生支持无限递归（MySQL 8.0+、PostgreSQL、SQL Server 支持 CTE），因此需分情况处理：
-
单层子节点：直接
WHERE parent_id = ?，加INDEX(parent_id)即可高效响应； -
所有后代（子树）：用递归 CTE（以 PostgreSQL 为例）：
WITH RECURSIVE tree AS ( SELECT id, name, parent_id, 1 AS level FROM categories WHERE id = 1 -- 起始节点 UNION ALL SELECT c.id, c.name, c.parent_id, t.level + 1 FROM categories c INNER JOIN tree t ON c.parent_id = t.id ) SELECT * FROM tree ORDER BY level;
-
从叶节点回溯到根（路径）：同样用递归 CTE，但方向相反 —— 从当前节点向上联结
parent_id，终止条件为parent_id IS NULL；
常见性能瓶颈与索引策略
邻接表最大隐患是“链式跳转”导致的多次随机 I/O。即使有索引，深度为 N 的树可能触发 N 次索引查找。
- 必须为
parent_id字段建立二级索引（如INDEX idx_parent (parent_id)），否则子节点查询会全表扫描； - 若频繁按层级+顺序展示（如菜单），可添加
(parent_id, sort_order)联合索引，让子节点按序取出更高效； - 避免在递归 CTE 中对大字段（如
TEXT）做计算或过滤 —— 先用 ID 递归收拢路径，再用结果集JOIN主表取详情；
轻量级优化：缓存路径或层级
不重构模型的前提下，可通过少量冗余显著提速：
- 增加
level字段（整数），记录节点深度。插入/移动节点时由应用或触发器维护。查询某层全部节点时可直接WHERE level = 3； - 增加
path字段（如'/1/5/12/'），用字符串存储完整祖先路径。支持前缀查询（path LIKE '/1/5/%'）快速定位子树，需INDEX(path)（注意前缀索引长度限制）； - 二者可共存：
level用于深度约束，path用于祖先/后代判断，兼顾灵活性与性能。
何时该换模型？
如果以下场景频繁出现，邻接表已成瓶颈，应评估其他方案：
- 需要高频查询“某节点的所有祖先”且树深 > 5，CTE 响应超 100ms；
- 业务要求原子性移动整棵子树（如拖拽分类），每次更新涉及数十行
parent_id； - 报表类查询需统计每层节点数、跨层级聚合，且数据量 > 百万级。
此时可考虑闭包表（Closure Table）或物化路径（Materialized Path）—— 它们用空间换时间，使大部分层级查询变为简单 JOIN 或范围扫描。
