MySQL用外键+ON DELETE CASCADE模拟组合（父删子必删），用外键+NO ACTION/软删除模拟聚合（子可独立存在）；二者均需手动实现，无自动嵌套级联。
MySQL 本身不支持对象组合语法，得靠外键 + JOIN 模拟
MySQL 是关系型数据库，没有类、属性、组合（composition）这些面向对象概念。所谓“模拟组合关系”，本质是用一对多外键约束 + 查询时显式关联，来表达「一个父记录拥有多个子记录」的语义。关键不是建模有多像 OOP，而是数据一致性是否可控、查询是否直观。
常见误区是强行套用 UML 组合符号（实心菱形），结果在 MySQL 里只建了外键却没加 ON DELETE CASCADE 或应用层校验，导致子记录变成孤儿数据。
- 组合（Composition）在数据库中对应强生命周期依赖：子记录不能脱离父记录存在，父删则子必须删
- 聚合（Aggregation）对应弱依赖：子记录可独立存在，父删不影响子（如用户删了，其历史订单仍要保留）
- MySQL 里二者都靠外键实现，区别只在
ON DELETE行为和应用逻辑
用外键 + ON DELETE CASCADE 实现组合语义
比如「订单（order）组合多个订单项（order_item）」：订单项无独立意义，必须属于某个订单。这时应在 order_item 表中定义外键，并启用级联删除：
CREATE TABLE `order` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE `order_item` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `order_id` BIGINT NOT NULL, `product_name` VARCHAR(100), `quantity` INT, FOREIGN KEY (`order_id`) REFERENCES `order`(`id`) ON DELETE CASCADE );
这样执行 DELETE FROM `order` WHERE id = 123 时，MySQL 自动删掉所有 order_item.order_id = 123 的行。这是最接近 OOP 中“组合”生命周期管理的方式。
-
ON DELETE CASCADE是强制组合语义的核心，漏写就退化成普通关联 - 注意：InnoDB 引擎才支持外键；MyISAM 忽略外键定义，等于没设
- 级联操作会锁表/行，高并发删大订单时可能影响性能
聚合场景下禁用级联，改用逻辑标记或软删除
比如「文章（article）聚合多个标签（tag）」：标签是全局共享资源，删除某篇文章不应删掉标签本身。此时外键仅用于关联，ON DELETE 应设为 NO ACTION（默认）或显式写出来：
CREATE TABLE `article` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `title` VARCHAR(200) ); CREATE TABLE `tag` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `name` VARCHAR(50) UNIQUE ); CREATE TABLE `article_tag` ( `article_id` BIGINT NOT NULL, `tag_id` BIGINT NOT NULL, PRIMARY KEY (`article_id`, `tag_id`), FOREIGN KEY (`article_id`) REFERENCES `article`(`id`) ON DELETE CASCADE, FOREIGN KEY (`tag_id`) REFERENCES `tag`(`id`) ON DELETE NO ACTION );
这里用了关联表 article_tag，对 article_id 用 CASCADE（删文章则清关联），对 tag_id 用 NO ACTION（删标签需先检查是否被引用）。
- 聚合的关键是「子实体可被多个父实体共享」，所以不能靠外键自动删子
- 真要删标签，得先查
SELECT COUNT(*) FROM article_tag WHERE tag_id = ?，确认无引用再删 - 有些团队会用软删除（加
is_deleted字段），但会增加所有查询的WHERE条件，权衡清楚
别指望 MySQL 自动维护组合嵌套深度
想模拟「订单 → 订单项 → 商品规格 → 库存快照」这种多层嵌套？MySQL 不会帮你递归验证或级联操作。每一层都得手动定义外键和 ON DELETE 策略，而且每多一层 JOIN，查询复杂度和锁竞争就明显上升。
例如三层组合：删订单 → 删订单项 → 删对应库存快照。你得确保：
-
order_item外键指向order并CASCADE -
inventory_snapshot外键指向order_item并CASCADE（注意：MySQL 允许外键引用非主键，但必须是唯一索引） - 事务包裹整个删除流程，避免中间状态不一致
实际项目中，超过两层的强组合往往意味着领域模型过重，更常见的做法是把深层子对象设计为事件驱动更新（如监听订单项插入后异步生成库存快照），而非强外键绑定。
