如何在MySQL中设计支持多层级分类的树状数据结构-mysql教程-PHP中文网

直接用 parent_id + with recursive 即可满足绝大多数多级分类需求，前提是 mysql ≥ 8.0；它轻量、易维护，避免闭包表写入开销和嵌套集更新风险，只需为 parent_id 加索引并合理使用递归语法。

如何在mysql中设计支持多层级分类的树状数据结构

直接用 parent_id + WITH RECURSIVE 就能跑通绝大多数多级分类场景，不需要额外建表或维护路径字段——但前提是 MySQL 版本 ≥ 8.0，且你接受单次查询最多几百行的性能边界。

为什么不用闭包表或嵌套集？

闭包表（tree_depth）和嵌套集（lft/rgt）确实能规避递归、提升查询速度，但代价明显：

闭包表写入开销大：每次新增/移动节点，都要批量插入多条祖先-后代关系记录
嵌套集更新成本高：挪动一个中间节点，可能要重刷整棵子树的左右值，极易出错且难加锁
两者都增加业务逻辑复杂度：后端增删改必须同步维护辅助表或左右值，不是纯数据操作

除非你有明确的千万级节点+高频遍历需求（比如大型电商类目导航），否则邻接模型更轻、更可控。

`parent_id` 字段必须加索引和外键吗？

必须加索引，外键可选但强烈建议加上：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

INDEX(parent_id) 是刚需：否则查某节点所有子节点（WHERE parent_id = ?）会全表扫描
FOREIGN KEY(parent_id) REFERENCES categories(id) 能防止脏数据（比如插入 parent_id = 999 但该 ID 不存在），但会拖慢批量导入；若导入频繁，可先删外键，导入完再校验并重建
parent_id 允许为 NULL：根节点靠它识别，别设成 0 或 -1，否则 WHERE parent_id IS NULL 查询失效

递归查询怎么写才不翻车？

MySQL 8.0+ 的 WITH RECURSIVE 是主力，但两个细节常被忽略：

锚点（anchor）必须用 WHERE parent_id IS NULL，不能写成 = 0 或 IS NOT NULL 取反，否则漏根或死循环
递归项里 JOIN 条件必须是 ON c.parent_id = ct.id（子找父），写反成 c.id = ct.parent_id 会导致结果为空
加 level 字段时，初始值建议设为 1（根是第 1 级），而不是 0，避免前端理解错位

示例片段：

WITH RECURSIVE cte AS (
  SELECT id, name, parent_id, 1 AS level
  FROM categories 
  WHERE parent_id IS NULL
  UNION ALL
  SELECT c.id, c.name, c.parent_id, cte.level + 1
  FROM categories c
  INNER JOIN cte ON c.parent_id = cte.id
)
SELECT * FROM cte ORDER BY level, id;