邻接表是关系型数据库中表示树形结构最常用方式，但查询整棵树、祖先/后代等操作低效；优化需减少递归次数、建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 或范围扫描。