设计分类导航表时，核心是支持层级结构（如一级分类、二级分类等），同时保证查询效率和扩展性。MySQL中常用的方法是使用自引用树结构，以下是几种实用的设计方案及建议。
1. 基础分类表设计（邻接列表模型）
这是最直观的方式，通过一个 parent_id 字段指向父级分类。表结构示例：
CREATE TABLE category ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT '分类名称', parent_id INT UNSIGNED DEFAULT 0 COMMENT '父级分类ID，0为根节点', sort_order TINYINT UNSIGNED DEFAULT 0 COMMENT '排序权重', status TINYINT(1) DEFAULT 1 COMMENT '状态：1启用，0禁用', created_at DATETIME DEFAULT CURRENT_TIMESTAMP );
特点：
结构简单，增删改操作方便。 适合层级不多（比如不超过3级）的场景。 缺点是查询所有子类或路径需要递归或多次查询。2. 路径存储法（Path Enumeration）
在记录中保存从根到当前节点的完整路径，便于查找子孙节点。修改表结构增加 path 字段：
ALTER TABLE category ADD COLUMN path VARCHAR(255) DEFAULT '' COMMENT '路径，如: 0-1-5';
示例数据：
id=1, name='图书', parent_id=0, path='0-1' id=5, name='小说', parent_id=1, path='0-1-5' id=6, name='科幻', parent_id=5, path='0-1-5-6'优势：
通过 LIKE 查询可快速获取某分类下的所有子类：SELECT * FROM category WHERE path LIKE '0-1-%';能还原出层级关系。
3. 闭包表（Closure Table）— 复杂但高效
适用于频繁查询层级关系的系统，单独建一张关系映射表。创建两张表：
-- 分类主表 CREATE TABLE category ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL, status TINYINT(1) DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); <p>-- 层级关系表 CREATE TABLE category_closure ( ancestor INT UNSIGNED NOT NULL COMMENT '祖先节点', descendant INT UNSIGNED NOT NULL COMMENT '后代节点', depth TINYINT UNSIGNED NOT NULL COMMENT '距离层级：0表示自己', PRIMARY KEY (ancestor, descendant), FOREIGN KEY (ancestor) REFERENCES category(id), FOREIGN KEY (descendant) REFERENCES category(id) );</p>
示例数据：
| ancestor | descendant | depth |
|---|---|---|
| 1 | 1 | 0 |
| 1 | 5 | 1 |
| 1 | 6 | 2 |
| 5 | 5 | 0 |
| 5 | 6 | 1 |
用途：
查某个分类的所有子类：SELECT c.* FROM category c JOIN category_closure cc ON c.id = cc.descendant WHERE cc.ancestor = 1;查上级路径（倒序）：
SELECT c.* FROM category c JOIN category_closure cc ON c.id = cc.ancestor WHERE cc.descendant = 6 ORDER BY cc.depth DESC;
4. 实际应用建议
如果分类层级固定且浅（如最多三级），推荐使用基础自引用 + path字段，兼顾简洁与性能。 若需频繁进行“查找所有子类”、“移动子树”等操作，建议采用闭包表模式。 添加索引提升查询速度：- 在 parent_id 上加索引（邻接模型）
- 在 path 字段上加索引（路径模型）
- closure 表的两个字段都应参与联合主键和索引 前端展示时，可缓存树形结构（如Redis），减少数据库压力。
基本上就这些。根据业务复杂度选择合适模型，大多数中小型项目用第一种加path就够了。
