下面专门针对部门、组织架构 这种典型层级数据，对比两种存储方式，讲清结构、优缺点、场景、性能、开发难度，面试直接背。
一、先定义两种结构
1. 树结构：自关联（父子级，最常用）
表设计：
sql
dept
id BIGINT PK
dept_name VARCHAR
parent_id BIGINT -- 父部门ID，根节点 parent_id = 0
sort INT本质： 一条记录只存「自己 + 直接父 ID」，通过递归 / 关联查所有子级。
2. 非树结构：扁平化 / 冗余路径法（非递归）
两种常见：
方案 A：冗余全路径（path）
sql
dept
id
dept_name
parent_id
path VARCHAR -- 存全路径，如：0,1,5,12
level INT -- 层级：1/2/3级方案 B：冗余每一级父 ID（固定层级）
适合层级固定（最多 3 级）：
sql
dept
id
name
level1_id -- 一级部门
level2_id -- 二级部门
level3_id -- 三级部门二、树结构（自关联 parent_id）：特点、优缺点
✅ 优点
- 结构最标准、最省字段，符合范式，无冗余；
- 无限层级，不管多少级部门都能存；
- 新增 / 修改 / 移动部门简单：只改自己和 parent_id；
- 适合通用树形组件：菜单、部门、分类通用一套逻辑；
- 数据干净，维护简单，不容易脏数据。
❌ 缺点
- 查询麻烦 ：查「某个部门下所有子部门」需要 递归 / CTE / 循环；
- MySQL 5.7 及以下不支持递归 CTE，只能用代码递归查，性能差；
- 大数据量层级深时，递归查询性能衰减明显；
- 批量统计（查某一级所有部门、统计所有下级人数）麻烦。
核心特点
- 存储：精简、无冗余
- 查询：递归查询
- 适合：层级不深、频繁新增 / 调整部门、无限层级
三、非树结构（冗余 path/level/ 多级 ID）：特点、优缺点
✅ 优点
- 查询极快 ：不用递归，用
like '%1,5%'就能查所有下级； - 支持 MySQL 5.7，不需要 CTE；
- 统计、筛选、导出非常方便；
- 适合大数据量、层级深的部门；
- 前端级联选择、筛选条件好做。
❌ 缺点
- 有冗余字段，违反范式；
- 移动 / 删除上级部门麻烦：需要同步更新所有下级的 path、level；
- 层级越多维护越复杂，容易出现脏数据（path 和 parent_id 不一致）；
- 固定层级方案只能支持固定几级，扩展性差。
核心特点
- 存储：冗余 path/level，空间换时间
- 查询：全路径匹配 like 快速
- 适合：层级深、查询多、调整部门少、5.7 老库
四、关键维度对比（直接背）
表格
| 对比维度 | 树结构（自关联 parent_id） | 非树结构（path/level 冗余） |
|---|---|---|
| 存储冗余 | 无冗余，符合范式 | 冗余 path/level，空间换时间 |
| 层级支持 | 无限层级，灵活 | 无限层级 (path) / 固定层级 |
| 查询下级 | 慢，需递归 / CTE | 快，like '% 路径 %' |
| 新增 / 修改 / 移动部门 | 简单，只改 parent_id | 复杂，需同步所有下级 path |
| 脏数据风险 | 低 | 高（path 和实际层级不一致） |
| MySQL 版本兼容 | 8.0 用 CTE，5.7 只能代码递归 | 全版本兼容 |
| 开发难度 | 递归构建树，稍复杂 | 简单，SQL 直接查 |
| 适用场景 | 频繁调整部门、层级不深、8.0+ | 查询频繁、层级深、5.7 老系统 |
五、总结与选型（面试必背）
1. 树结构（自关联 parent_id）总结
- 本质：标准树形存储，一条记录只存直接父级；
- 优势：结构标准、维护简单、无限层级、少冗余；
- 劣势：查询下级慢，依赖递归 / CTE；
- 选型 ：MySQL8.0、部门频繁调整、层级不深、追求规范，优先用自关联。
2. 非树结构（path/level）总结
- 本质：冗余全路径，用空间换查询性能；
- 优势：查询极快、不用递归、兼容 5.7；
- 劣势：维护复杂，移动部门要批量更新下级；
- 选型 ：MySQL5.7、部门查询多、层级深、调整少，用 path 冗余。
一句话选型口诀
频繁改、层级浅、8.0 → 自关联树结构； 频繁查、层级深、5.7 → path 冗余非树结构。
六、面试高频问题标准答案
Q1：部门表为什么常用自关联树结构？
答：自关联结构符合树形层级关系，字段精简无冗余，支持无限层级，新增、移动部门维护简单，符合数据库设计范式；缺点是查询子部门需要递归，适合 MySQL8.0 使用 CTE 优化。
Q2：什么场景下不用自关联，用 path 冗余？
答：MySQL5.7 不支持递归 CTE、部门层级很深、查询子部门非常频繁、部门结构很少变动，此时用 path 冗余，通过 like 快速查询，牺牲少量存储换查询性能。
Q3：两种结构的核心 trade-off 是什么？
答：自关联：维护简单、查询复杂；path 冗余：维护复杂、查询简单。