应选用Adjacency List模型，因其增删改简单且Navicat最适配；需在Navicat Data Modeler中手动设置parent_id外键指向本表id，避免画自引用连线，并确保逆向工程后补全外键约束。
树形分类（如商品类目、组织架构、文章目录）在数据库里不能靠“画个树”实现，得靠表结构设计 + 递归查询逻辑。navicat 本身不提供“拖拽生成树形表”的功能，但能帮你可视化建模、验证关系、生成脚本——关键是你得先想清楚用哪种树形结构模型。
该用 Adjacency List 还是 Nested Set？
这是建模前必须做的选择，直接影响后续查询性能和维护成本：
-
Adjacency List（邻接表）：最常见，每个节点存一个parent_id字段指向父节点。优点是增删改简单，缺点是查某节点的完整路径或所有子树需要递归（MySQL 8.0+ 支持WITH RECURSIVE，旧版本就得靠应用层拼 SQL） -
Nested Set（嵌套集）：每个节点存lft和rgt两个整数，用区间表示层级关系。优点是查子树、深度、路径极快，缺点是插入/移动节点要更新大量行，且 Navicat 不会自动帮你维护这两个字段 - 别用 Closure Table（闭包表）：虽然更灵活，但在 Navicat 建模时没法直观体现“父子-祖先”多对多关系，容易在模型里画错连线，实际项目中反而增加理解成本
绝大多数中小系统选 Adjacency List 更稳妥，Navicat 也最适配这种结构。
在 Navicat Data Modeler 中建模要点
不是随便画个“分类表”就完事，模型要体现树形语义，否则导出的 DDL 会漏关键约束：
- 表名建议用
category或tree_node，字段至少包含：id（主键）、name、parent_id（允许 NULL，根节点设为 NULL）、sort_order（可选，用于同级排序） - 必须手动添加外键：右键
parent_id字段 → “编辑外键”，指向本表的id。Navicat 不会自动识别自引用关系，漏这步导出的 SQL 就没外键约束 - 别在模型里画“自己连自己”的关系线：Navicat 的连线工具对自引用支持不稳定，容易导出错误的
FOREIGN KEY语法。正确做法是只设外键，不画线 - 如果要用 MySQL 8.0+ 的递归查询，记得在模型属性里把数据库版本设为 8.0+，否则 Navicat 可能默认生成不兼容的 DDL
逆向工程已有树形表时的坑
如果你是从旧库“逆向生成模型”，Navicat 很可能把 parent_id 当成普通字段，忽略其自引用外键：
- 操作路径：右键数据库 → “逆向模式到模型”，生成后立刻检查模型里该表的外键列表 —— 如果没看到
parent_id → id这条，就得手动补 - Navicat 逆向时对自引用外键识别率低，尤其当字段名不是标准的
parent_id（比如叫pid或up_id），它基本不会猜 - 补外键后，记得点“同步到数据库”前先预览 SQL：Navicat 生成的
ALTER TABLE ... ADD CONSTRAINT语句可能带引号或大小写问题，MySQL 严格模式下会失败
真正难的不是画图，而是想清楚“哪些操作频次高”——如果频繁查子树，Adjacency List 就得搭配应用层缓存；如果频繁移动节点，Nested Set 的维护逻辑必须独立封装，不能依赖 Navicat 自动生成。模型只是起点，别让它替你做业务决策。
