不能用 category_id + spec_id 两个字段凑合存菜品表，因为混淆了“归属关系”（菜品→分类，一对多）与“组合实例”（菜品×规格组合，多对多），导致无法管理独立库存、价格、SKU及前端规格选择；正确做法是三张主表加两张中间表，其中规格组合用 JSON 或规范化多对多建模，并确保 sku_code 业务生成。
直接用一张表硬塞分类+规格字段，短期能跑，但两周后就会遇到「同一菜品在不同分类下价格/库存不一致」「规格改名全表UPDATE」「查「小杯热奶茶」在「饮品」和「新品」两个分类下的销量总和」时SQL又臭又慢」——这不是设计，是埋雷。
为什么不能用 category_id + spec_id 两个字段凑合存菜品表？
很多人在 menu_items 表里加 category_id 和 spec_id，以为这就“支持多对多”了。错在混淆了「归属关系」和「组合实例」：
-
category_id是菜品所属分类（一对多），比如「珍珠奶茶」属于「饮品」 -
spec_id是规格定义（如「小杯」「热」「加糖」），但一个菜品可以同时有多个规格组合（小杯热、大杯冰、中杯少糖…） - 这两个维度交叉后，实际售卖单元是「菜品 × 规格组合」，不是「菜品 × 分类」或「菜品 × 单个规格」
强行把 spec_id 当成单值字段，会导致：无法记录「小杯热」和「大杯冰」的独立库存、价格、SKU编码；前端选规格时没数据源；导出报表时分不清是「销量按规格统计」还是「按分类统计」。
标准做法：三张表 + 中间表建模「菜品-分类」和「菜品-规格组合」
真正可落地的结构是分离两层关系：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
categories：只管分类本身（id, name, sort_order） -
specs：只管规格定义（id, name, type 如「size」「temperature」「sweetness」） -
menu_items：只管菜品本体（id, name, description） -
menu_item_categories：中间表，记录menu_item_id→category_id（一对多可变，支持一个菜品进多个分类） -
menu_item_spec_combinations：中间表，记录每个「菜品+规格组合」的完整实例（含 price, stock, sku_code, is_available）
示例建表语句（关键字段已标注）：
CREATE TABLE menu_item_spec_combinations ( id BIGINT PRIMARY KEY AUTO_INCREMENT, menu_item_id BIGINT NOT NULL, spec_combination_json JSON NOT NULL, -- 存 ['size:large', 'temp:ice', 'sweet:half'] 这种规范数组 price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, sku_code VARCHAR(64) UNIQUE, is_available TINYINT UNSIGNED NOT NULL DEFAULT 1, FOREIGN KEY (menu_item_id) REFERENCES menu_items(id) ON DELETE CASCADE );
注意：spec_combination_json 比拆成几十个外键字段更灵活，MySQL 5.7+ 支持 JSON 函数查询（如 JSON_CONTAINS），且避免了无限扩张的冗余字段；如果业务要求强结构化（如必须校验「每种规格类型只能选一个值」），再拆成 menu_item_specs + 多对多中间表。
查询「某分类下所有可售规格组合」时容易踩的 JOIN 陷阱
常见错误写法：SELECT * FROM menu_items mi JOIN menu_item_categories mic ON mi.id = mic.menu_item_id JOIN menu_item_spec_combinations msc ON mi.id = msc.menu_item_id WHERE mic.category_id = 123 AND msc.is_available = 1 —— 看似合理，实则会漏掉「该菜品属于分类123，但某个规格组合已售罄」的情况，因为 msc.is_available = 1 把整条 JOIN 记录过滤掉了，而你真正需要的是「分类内所有菜品，及其各自可用的规格组合列表」。
- 正确思路：先查出分类下的所有菜品 ID，再用
IN或EXISTS查对应规格组合，避免隐式笛卡尔积 - 性能关键：给
menu_item_categories(category_id, menu_item_id)加联合索引（idx_category_item），给menu_item_spec_combinations(menu_item_id, is_available)加联合索引（idx_item_avail） - 别依赖
GROUP_CONCAT把规格组合拼成字符串返回——前端解析成本高，且无法按规格条件筛选（比如只要「冰」款）
最易被忽略的一点：规格组合表里的 sku_code 必须业务生成（如 ITEM123-LARGE-ICE-HALFSWEET），不能靠数据库自增ID。否则扫码核销、库存同步、第三方对接时，根本没法和外部系统对齐实体。这个字段看着小，却是整个订单履约链路的锚点。
