不能用单张表存菜单和分类，因会导致分类名重复、改名全表更新、无法约束有效性、LIKE查询低效不准；标准方案是categories和menu_items两张表加外键约束，支持ON DELETE RESTRICT防孤儿、sort_order可控排序，并通过自引用或扩展表应对多级分类与多语言需求。
为什么不能用单张表存菜单和分类？
直接在 menu_items 表里加个 category_name 字符串字段，短期看着省事，但很快会出问题：分类名重复（比如“辣子鸡”和“辣子鸡丁”都算“川菜”，但字符串不一致）、改名要全表更新、无法约束分类有效性、查某分类下所有菜品时 LIKE 效率低且不准。
标准一对多关联表结构怎么建？
用两张表 + 外键约束最稳妥：
CREATE TABLE categories ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL UNIQUE, sort_order TINYINT DEFAULT 0, is_active BOOLEAN DEFAULT TRUE ); CREATE TABLE menu_items ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL, price DECIMAL(6,2) NOT NULL, category_id INT NOT NULL, description TEXT, is_available BOOLEAN DEFAULT TRUE, FOREIGN KEY (category_id) REFERENCES categories(id) ON DELETE RESTRICT );
关键点：
-
categories.id是主键，menu_items.category_id是外键，强制关联有效 -
ON DELETE RESTRICT防止误删分类导致菜单项变“孤儿” -
sort_order字段比用名称排序更可控，前端按此字段查分类列表 - 别给
category_id加INDEX—— 外键自动建索引，重复加反而拖慢写入
遇到多级分类（如“川菜 > 热菜 > 宫保系列”）怎么办？
如果真需要三级以上分类，不要强行塞进两张表。先确认业务是否真需要——多数点餐系统“一级分类+标签”就够了（例如用 categories 存“川菜”“粤菜”，再加一张 tags 表存“宫保”“酸辣”“素食”，用中间表 menu_item_tags 关联）。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
若必须多级，用自引用设计：
ALTER TABLE categories ADD COLUMN parent_id INT NULL; ALTER TABLE categories ADD FOREIGN KEY (parent_id) REFERENCES categories(id);
但要注意：
- 查某一级分类下的所有子项（含孙项）需递归查询，MySQL 8.0+ 才支持 CTE，低版本得用程序层拼或临时表
- 一个菜品只能属于一个最细分类（比如“宫保鸡丁”属于“宫保系列”，不再同时属于“热菜”），否则得改用闭包表或路径枚举，复杂度陡增
- 管理后台做分类树时，注意防止循环引用（
A→B→A），应用层校验比数据库约束更实际
上线后发现分类要支持多语言或 SEO 友好 URL 怎么办？
别动主表结构。加扩展表更安全：
CREATE TABLE category_translations ( category_id INT NOT NULL, locale CHAR(5) NOT NULL COMMENT 'en_US, zh_CN', name VARCHAR(50) NOT NULL, slug VARCHAR(64) COMMENT '用于 URL，如 chuan-cai', PRIMARY KEY (category_id, locale), FOREIGN KEY (category_id) REFERENCES categories(id) ON DELETE CASCADE );
这样原始 categories.name 可作为默认值兜底，前端按用户 locale 查对应翻译，URL 用 slug 而非 ID，既不影响现有逻辑，又留出扩展余地。唯一容易被忽略的是：slug 必须全局唯一（哪怕跨语言），否则路由冲突，建议加联合唯一索引 (locale, slug)。
