为什么不推荐使用外键？

外键会**影响性能、增加锁竞争、限制分库分表的灵活性**，在高并发场景下不推荐使用。通常采用**应用层保证数据一致性**，而不是依赖数据库外键约束。 ### **1. 外键的作用** - **保证数据一致性**：确保外键字段的值在主表中存在，防止数据孤立。 - **防止非法删除**：阻止删除仍被引用的数据，维护数据完整性。 示例： ```sql CREATE TABLE orders ( order_id INT PRIMARY KEY ); CREATE TABLE order_items ( item_id INT PRIMARY KEY, order_id INT, FOREIGN KEY (order_id) REFERENCES orders(order_id) ON DELETE CASCADE ); ``` 如果 `orders` 中的 `order_id` 被删除，则 `order_items` 中对应的记录也会被删除。 ### **2. 为什么不推荐使用外键？** #### **1️⃣ 影响性能** - **每次插入、更新、删除数据时，数据库必须检查外键约束**，增加开销。 - **维护额外的索引**，影响写入性能，特别是高并发场景。 #### **2️⃣ 增加锁竞争，可能导致死锁** - **插入、更新、删除时，外键检查需要锁定主表**，影响并发性能。 - **多个事务同时操作外键相关的表**，容易发生**死锁**。 #### **3️⃣ 不适应分库分表** - **外键无法跨库**，一旦数据量大了需要拆分，外键就无法继续使用。 - **在分库分表场景下，数据一致性需要通过应用层保证，而不是外键**。 #### **4️⃣ 逻辑删除不兼容** - **外键是物理约束**，而很多业务采用**逻辑删除（如 `is_deleted` 标志位）**，外键可能导致删除受限，无法灵活管理数据。 ### **3. 解决方案：如何保证数据一致性？** ✅ **应用层校验** - 在**业务代码中**检查外键约束，而不是让数据库管理： ```java if (!orderExists(orderId)) { throw new RuntimeException("Order ID does not exist"); } ``` ✅ **使用事务保证一致性** - 在同一个事务中先创建主表数据，再插入子表数据： ```sql START TRANSACTION; INSERT INTO orders (order_id) VALUES (1001); INSERT INTO order_items (item_id, order_id) VALUES (1, 1001); COMMIT; ``` ✅ **采用消息队列（MQ）处理数据一致性** - 在分库分表环境下，可以使用**事件驱动架构**，让数据同步到正确的库。 ### **4. 结论** - 外键虽然能保证数据一致性，但在高并发场景下会**影响性能、增加锁竞争、限制分库分表的灵活性**。 - 大型互联网公司通常**不使用外键**，而是通过**应用层校验、事务、消息队列**等方式保证数据一致性。