前两天帮一位后端同事排查线上问题那条 SQL 明明只是删一条客户数据结果卡了四十多秒还没结束数据库连接池都快被拖垮了。我让他先停了跑批任务查了一下锁等待罪魁祸首就是订单表上有个外键引用了客户表删主表数据的时候子表的引用约束检查一直在等锁。这种场面相信不少人都遇到过外键这个东西建表时加一条约束很容易真正考验人的是它后续带来的一系列引用完整性、性能、锁竞争和迁移问题。这篇内容就把外键引用的核心问题从头到尾捋一遍包括外键约束的设计思路、级联策略怎么选、建表和排查的实操步骤、性能锁和分库分表场景下的取舍技巧、以及我踩过的坑和解决办法。适合正在被外键约束困扰的后端开发、DBA还有刚接触关系数据库不久、想搞明白外键到底该怎么用的朋友。1. 外键引用到底在保护什么先把数据完整性问题讲透1.1 外键的本质是一道“数据红线”外键引用Foreign Key不是索引也不是单纯的字段关系它是数据库层面的一种约束规则。它的核心作用是保证两个表之间的引用关系成立子表里存的值必须在父表的主键或唯一键里真实存在。你可以把它理解成一道数据红线跨过去的数据操作会被数据库直接拦下来。举个最常见的例子订单表里有个 customer_id这个字段逻辑上必须指向客户表里真实存在的一条记录。如果没有外键约束业务代码一旦出现并发问题、时序问题或者人为误操作就可能写进去一个 customer_id 9999但客户表里根本没有这个客户。这样的数据在应用层看没什么异常等到做数据分析、对账、或者关联查询的时候就会莫名其妙多出一些永远对不上的“幽灵记录”。外键约束存在的最直接价值就是让数据库替你把这道防线守住。你不需要在每一段写代码的时候都手写一次“先查客户表是否存在”数据库在写入和修改时自动完成这个校验。这不只是省几行代码的问题更重要的是它消灭了一整类潜在的数据不一致故障。1.2 没有外键时数据是怎么悄悄坏掉的我见过不少项目在早期为了“方便”把外键全去掉了结果数据一致性问题全靠业务代码补救往往落到实处就漏了。给你举个典型的损坏路径用户下单时订单服务和用户服务是两个团队维护的两边代码各自独立部署。某次版本发布顺序没协调好订单服务先上线调用的用户服务接口已经不支持旧格式了接口报错但订单表的数据还是被某个兜底逻辑写进去了。这种脏数据出现后如果订单表有外键指向用户表写入直接失败问题在第一时间就能暴露出来没有外键的话脏数据就静默入库了。后续用户来投诉“我明明没下单为什么扣款了”排查半天才发现是数据串了。更隐蔽的还有一种删除业务数据的时候只删了父表没删子表。比如关闭了一个门店门店表里记录删了但门店的订单明细还在后续财务报表按门店维度汇总这些明细就成了无主数据金额差异对不上。如果当初建外键的时候设置了合适的级联策略或者用了 RESTRICT 禁止直接删除这个问题从源头上就不会发生。所以我的建议很明确不要因为外键“麻烦”就直接砍掉。外键在中小型的单体系统里是性价比极高的数据保护机制。只有你真正遇到了性能瓶颈或者架构拆分需求再考虑用其他方案替代它这个决策应该是一个权衡过程而不是一上来就无脑禁用。2. 建表前必须定好的外键策略级联、置空还是拒绝2.1 删除和更新策略的选择决定了数据命运外键约束在定义时除了指定“子表哪个字段引用父表哪个字段”之外最重要的一件事是决定父表记录被删除或更新时子表的数据要怎么处理。这个策略就是 ON DELETE 和 ON UPDATE一共四种主流选择我整理成了表格方便你对比策略作用适用场景风险点CASCADE父表删除/更新时子表关联数据跟着删除/更新父子数据生命周期完全一致比如订单头与订单明细误删父表会连带删掉大量子表数据要谨慎SET NULL父表删除/更新时子表外键字段置为 NULL子表记录还需要保留但关联关系解除比如审批记录里的审批人离职外键列必须允许 NULL否则建约束会失败RESTRICT存在子表关联时直接拒绝父表删除/更新需要强一致、不允许有失去引用的数据会阻碍正常的父表数据清理需要额外处理NO ACTION跟 RESTRICT 类似但检查时机略有差异MySQL InnoDB 里与 RESTRICT 等价PostgreSQL 里可配合延迟约束使用需要理解数据库本身的默认行为和约束检查时机举个实际选型例子员工表和部门表。员工归属部门部门被撤销时通常有两种做法一是把该部门员工全部裁掉这时用 ON DELETE CASCADE部门一删员工全没了二是部门解散但员工还在等待调入新部门这时应该用 ON DELETE SET NULL把员工的 department_id 置空。如果部门负责人不同意员工被误删那就用 RESTRICT先把员工数据处理好再删部门。ON UPDATE 策略相对用得少因为严格来说业务主键不应该被修改。但如果你的父表主键确实可能变化比如部门编号从 001 调整为 100ON UPDATE CASCADE 可以让子表引用自动跟着变省去手动 UPDATE 的麻烦。PostgreSQL 里默认策略是 NO ACTIONMySQL InnoDB 里默认等价于 RESTRICT你可以显式写清楚不给数据库“自由发挥”的空间。2.2 复合外键当业务关联关系不止一列时有些业务场景下子表引用的不是父表的主键而是父表的联合唯一键。举个实际例子一个订单系统里order_items 明细表要引用 product 表但产品唯一标识不是单个字段而是 brand_code product_code 两个字段的组合。此时就需要在 order_items 表上建立复合外键-- PostgreSQL 示例 CREATE TABLE order_items ( id BIGSERIAL PRIMARY KEY, order_id BIGINT NOT NULL REFERENCES orders(id), brand_code VARCHAR(20) NOT NULL, product_code VARCHAR(20) NOT NULL, quantity INT NOT NULL, FOREIGN KEY (brand_code, product_code) REFERENCES product(brand_code, product_code) );复合外键有一个常见的坑外键列的顺序和父表被引用唯一键的顺序必须完全一致而且一一对应不能只包含其中一部分。比如父表唯一键是 (brand_code, product_code)子表外键写成 (product_code, brand_code) 或者只引用 product_code数据库都会直接报错。设计的时候最好把列名也统一命名减少心智负担。复合外键的另一个特征是它往往也会在子表上形成一个天然的索引结构对按 brand_code product_code 查询有所帮助。但要注意这个组合索引的最左前缀是生效的如果你的查询只用到 product_code那就不会走这个复合索引需要额外评估索引方案。2.3 自引用外键一张表内部的树形关系外键也可以引用自己所在的表这在组织架构、树形分类、评论回复等场景非常常见。比如员工表里有一个 manager_id 引用员工的 id就能用一张表表达完整的上下级关系。CREATE TABLE employee ( id BIGSERIAL PRIMARY KEY, name VARCHAR(50) NOT NULL, manager_id BIGINT REFERENCES employee(id) );自引用外键最大的问题依然是删除策略。一个主管下面管着几十个员工如果你想删掉这位主管同时把他的下属交给另一个主管接管那么直接用 CASCADE 会把人全部删光显然不是你要的效果。合理做法是把 manager_id 设置成允许 NULL删除主管后通过 SQL 先把下属的 manager_id 更新为新主管再删除主管记录或者直接使用 SET NULL 先解除关系再分配。在递归查询场景比如查整个组织树下所有员工自引用外键本身不参与 SQL 逻辑真正干活的是 WITH RECURSIVE但外键约束能确保你构建的树不会出现指向不存在节点的坏边。这个保护在树形结构里尤其重要因为一旦出现循环引用或者悬空引用递归查询很容易死循环或者丢失数据。2.4 外键列到底要不要单独建索引这个问题我见过很多新人会忽略实际上它是外键设计里最容易被忽略的性能细节之一。MySQL 的 InnoDB 引擎有一个比较省心的行为如果你建外键时发现对应列上没有索引它会自动创建一个索引所以很多时候你没主动加索引也不会出问题。但 PostgreSQL 不会替你创建索引如果你不手动建删除或更新父表记录时数据库需要扫描整个子表来确认哪些行引用了目标记录数据量一大性能就会剧烈恶化。我参与过一个订单系统的性能优化订单明细表有 3000 万行外键指向订单头表。因为当初建表时没给明细表的外键列建索引每次清理已经删除的订单头数据时数据库要全表扫订单明细跑一次要二十多分钟而且把磁盘 IO 打满。后来加了索引同样的清理任务从半小时降到三秒左右差距就是这么夸张。所以任何数据库里外键列都值得显式建立索引不要想当然觉得数据库都帮你处理好了。3. 从建表到排障外键引用的完整实操流程3.1 业务建模与建表实操我习惯在建模阶段就把外键关系画出来再落到 DDL。下面用一个简化但完整的示例来演示客户、订单、订单明细三张表它们之间的外键关系是订单指向客户订单明细指向订单。先建父表再建子表。虽然某些数据库支持在同一批 DDL 里处理前向引用但为了可读性和降低出错率我建议严格按照依赖顺序执行-- 客户表 CREATE TABLE customers ( id BIGSERIAL PRIMARY KEY, name VARCHAR(50) NOT NULL ); -- 订单表引用客户表 CREATE TABLE orders ( id BIGSERIAL PRIMARY KEY, customer_id BIGINT NOT NULL, status SMALLINT NOT NULL DEFAULT 0, created_at TIMESTAMP NOT NULL DEFAULT now(), CONSTRAINT fk_orders_customer FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE RESTRICT ON UPDATE CASCADE ); -- 订单明细表引用订单表 CREATE TABLE order_items ( id BIGSERIAL PRIMARY KEY, order_id BIGINT NOT NULL, product_name VARCHAR(200) NOT NULL, quantity INT NOT NULL, CONSTRAINT fk_order_items_order FOREIGN KEY (order_id) REFERENCES orders(id) ON DELETE CASCADE ON UPDATE CASCADE );注意这里我做了个有意思的差异设计订单和客户之间用 RESTRICT业务上不允许删除有订单历史的客户订单和明细之间用 CASCADE因为明细的生命周期完全跟随订单。这正好呼应了前面说的策略选择逻辑同一个系统里不同关系可以有不同的策略不要一张表一个策略用到头。我还建议给外键命名时遵循“fk_子表_父表_列名”的格式像上面的 fk_orders_customer。如果不显式命名MySQL 和 PostgreSQL 会生成一长串默认名后续排查报错时你很难一眼看出是哪个字段出了问题。建表之后如果你用的是 ORM 的自动建表功能我建议你手动检查一下最终 DDL 里外键是否真的生效了。因为有些 ORM 配置不正确时外键会被悄悄跳过表建出来了但约束没建你以为有保护实际上裸奔。3.2 模拟外键行为插入失败、更新级联、删除被拒表建完之后一定要做一轮行为验证确认约束真的按你的策略工作。这种验证一旦出了问题代价是相当大的。先验证 RESTRICT 的行为-- 插入一个不存在客户的订单应该直接报错 INSERT INTO orders (customer_id, status) VALUES (9999, 1); -- ERROR: insert or update on table orders violates foreign key constraint fk_orders_customer这个报错就是外键在兜底。如果没有这条约束这条脏数据就进去了。再验证 CASCADE 和 SET NULL 的行为。先插入一个客户再插入订单然后删除客户观察订单是否被自动删除或者删除订单头时订单明细是否被清理INSERT INTO customers (name) VALUES (某测试客户); INSERT INTO orders (customer_id, status) VALUES (currval(customers_id_seq), 1); INSERT INTO order_items (order_id, product_name, quantity) VALUES (currval(orders_id_seq), 测试商品, 2); -- 删除订单头观察明细是否被级联删除 DELETE FROM orders WHERE id currval(orders_id_seq); SELECT COUNT(*) FROM order_items WHERE order_id currval(orders_id_seq);执行完上面的验证你应该看到订单和明细都同步消失了。如果结果不符合预期说明你的策略配置和预想的不一致应该尽早调整不要等到生产环境出现问题再回头查。3.3 查看外键、临时禁用约束与恢复的技巧日常维护中你可能需要查看某张表上都有哪些外键。MySQL 可以查 information_schemaPostgreSQL 可以查 pg_constraint-- MySQL 查看某个库下所有外键信息 SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA your_db AND REFERENCED_TABLE_NAME IS NOT NULL; -- PostgreSQL 查看某张表的外键定义 SELECT conname, conrelid::regclass AS table_name, pg_get_constraintdef(oid) FROM pg_constraint WHERE contype f AND conrelid orders::regclass;临时禁用外键检查是运维阶段常用的手段。MySQL 里可以用全局变量关闭外键检查注意这个操作会跳过所有外键约束执行期间数据库处于“裸奔”状态SET FOREIGN_KEY_CHECKS 0; -- 执行你的数据清理或导入操作 SET FOREIGN_KEY_CHECKS 1;PostgreSQL 不支持直接全局开关外键检查但如果你建表时把约束声明为可延迟就可以在事务内延迟约束检查BEGIN; SET CONSTRAINTS fk_orders_customer DEFERRED; -- 先删除后补齐或者调整数据顺序 COMMIT;需要特别强调的是临时禁用外键检查只适合在明确知道自己在干什么的场景下使用。比如批量导入历史数据时数据源本身可能存在部分依赖不完整先关掉约束导完再修数据最终再恢复约束并做一致性校验。最怕的是关了外键检查之后忘记打开后续业务流程照跑脏数据一批批溜进去等你发现的时候已经积重难返了。3.4 已有脏数据时如何安全补上外键约束还有一种非常常见的现实场景线上系统从一开始就没建外键运行了大半年已经有部分历史数据不满足引用完整性。这时候你直接 ALTER TABLE 加外键数据库会校验全表数据发现存在孤儿记录直接报错拒绝执行。我的处理思路是分四步走先找出不满足引用关系的脏数据。根据业务规则修复或清理这些脏数据。再执行加外键的 ALTER 语句。对加约束前后做一次数据校验确认没有产生新的问题。找出脏数据的 SQL 本质上就是一次 LEFT JOIN 反查SELECT o.* FROM orders o LEFT JOIN customers c ON c.id o.customer_id WHERE c.id IS NULL;这条 SQL 会把所有 customer_id 在客户表中找不到对应记录的订单列出来。拿到清单后再和业务方确认这些订单是应该补上客户、删除还是置成特殊值。这个确认过程不能省我是一个一个核对过来的跳过这一步后续还得返工。数据修复完之后执行ALTER TABLE orders ADD CONSTRAINT fk_orders_customer FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE RESTRICT;这个过程中最耗时的其实不是 ALTER TABLE 本身而是脏数据的梳理和业务确认。所以我的经验是新系统建表时就把外键设计好不要在事后补课补课的成本往往比最初设计时高出一个数量级。4. 外键不是免费的性能、锁机制和架构取舍4.1 外键的写入路径上多了哪些开销外键约束不是白送的每次向子表插入或更新外键列时数据库都需要去父表检查引用键是否存在。这个检查本质上等同于一次索引查询。对单条写入来说这个额外开销通常只有零点几毫秒几乎无感但在批量写入、高并发写入场景下它会造成可感知的影响。我做过一次对比测试在同样的数据规模下批量插入一万条子表记录有外键约束和无外键约束的耗时差距大约在 15% 到 25% 之间。而且这个差距会随着父表变大、父表索引命中率下降以及事务复杂度的提升而扩大。如果你是一个纯离线写入系统或者报表归档系统对写入吞吐极其敏感外键确实是可以考虑去掉的。但反过来也要说句公道话如果你用应用层代码来替代外键做存在性检查同样需要执行一次父表的查询而且代码里漏掉并发风险的概率更高。也就是说外键带来的开销本质上“买”到了一层自动化的完整性保护。单纯因为“性能”砍掉外键却没在应用层补一套等价校验逻辑这其实是在回避问题不是解决问题。4.2 删父表数据被卡住多半是锁在作祟外键和锁的关系是最容易踩雷的地方。删除或更新父表数据时数据库需要扫描子表确认有多少行引用了目标记录这个行为天然会引入锁竞争。以 MySQL InnoDB 为例当你在子表上执行 UPDATE 或 DELETE 语句修改外键列时InnoDB 除了锁住子表的目标行还会在父表对应的引用行上加一个共享锁防止在子表事务完成之前父表记录被删除或主键被修改。反过来如果父表上的删除事务正在等待子表上的锁而子表上又有一个事务在等待父表的锁两边就形成死锁InnoDB 会选择回滚其中一方来解除死锁。我排查过的一次外键死锁场景是这样的事务 A 删除了父表记录同时需要检查子表的未提交事务事务 B 往子表插入了一行触发了父表引用键的共享锁请求但父表记录已经被事务 A 删除于是 B 等待 A 释放A 又等待 B 先提交子表的写入。两个事务互相等最终死锁。解决思路通常是缩短事务长度保证父表和子表的操作顺序一致并且尽量让所有相关操作在同一个事务里按固定顺序执行。PostgreSQL 的锁机制略有不同但核心矛盾是类似的删除父表记录时如果子表上没有合适的索引数据库就得扫子表扫描期间大量行会被锁保护持锁时间拉长其他事务排队等待表现就是“一条 DELETE 把所有写入都堵住了”。给外键列加上索引是缓解锁竞争最直接的手段能让数据库快速定位到存在引用的子表行而不是扫描全表、扩大锁范围。这也是我在 2.4 里为什么要强调索引的原因。4.3 什么时候该放弃外键放弃之后靠什么兜底外键在分库分表和微服务架构面前确实会遇到挫折。同一个订单可能被拆分到订单库、用户库、商品库物理上的分布式环境下关系型数据库自带的外键无法跨库生效。这时候常规做法是在应用层自行维护引用关系但必须有配套的兜底手段。我梳理了一套可落地的替代方案按重要程度排序应用层强校验写订单时先从用户服务查询客户是否存在不存在则直接拒绝模拟外键的“写入检查”功能。软删除取代物理删除客户记录不真正删除而是打上状态标记所有订单依然能指向这个客户从根源上避免引用悬空。定期对账任务每天扫描订单表中 customer_id 找不到对应客户的记录产出异常清单触发告警和修复流程。归档库加回外键核心业务库可以放弃外键换取性能但归档数据库和只读分析库建议把外键加回来毕竟这些库写入压力低约束的成本可接受还能保障历史数据质量。我还想提醒一点任何放弃外键的决策都应该以书面形式记录下来并且明确新的数据完整性责任人。最怕的是“去外键”变成了一个口号大家只记得删掉了约束却没人负责补上对账机制系统运行几个月后数据烂成一锅粥还得逐张表手工清理。5. 外键问题排查实录报错、卡顿和误删的应对5.1 插入或更新失败外键约束冲突的排查路径最常见的报错形式是“Cannot add or update a child row: a foreign key constraint fails”或 PostgreSQL 的 “violates foreign key constraint”。遇到这个报错时我的排查顺序是固定的按步骤来基本不会跑偏。第一步先确认子表写入的外键值在父表中是否真实存在。这一步可以用 LEFT JOIN 反查也可以用一条简单的 SELECT 确认SELECT id FROM customers WHERE id 9999;如果查不到说明写入的数据本身就有问题需要回到业务侧看这个外键值是从哪里来的为什么引用了不存在的记录。第二步如果父表确实存在该记录就要考虑字段类型或约束的兼容性问题。MySQL 里外键列和引用列的类型必须几乎完全一致比如父表是 BIGINT子表是 INT建表时可能不报错但某些版本下执行写入会异常。字符集和排序规则不一致也会导致问题。PostgreSQL 对类型要求同样严格INT 和 BIGINT 不匹配时 ALTER TABLE 直接失败。第三步检查是否因为外键列本身有重复值或 NULL 值。如果外键列允许 NULL而约束设置的是 SET NULL 策略NULL 是合法的但如果外键列上有唯一索引多个 NULL 又有可能引发其他冲突。总之要结合表结构和数据状况一起判断。5.2 删除父表记录卡死锁等待和长事务排查前面提到过删除卡死的现象真正排查起来其实不复杂你只需要找到谁在等待谁的锁。MySQL 下可以先看当前有哪些锁等待SELECT * FROM information_schema.innodb_lock_waits\G或者直接 SHOW ENGINE INNODB STATUS里面有一段 LATEST DETECTED DEADLOCK 和锁等待的详细信息能明确显示哪个事务持有锁、哪个事务在等待。PostgreSQL 下可以这样查SELECT blocked.pid AS blocked_pid, blocking.pid AS blocking_pid, blocked.query AS blocked_query, blocking.query AS blocking_query FROM pg_stat_activity blocking JOIN pg_stat_activity blocked ON blocking.pid ANY(blocked.pg_blocking_pids());定位到阻塞源后通常有两种结局一种是另一个事务还开着没提交你把它的 SQL 查出来确认是否应该提前结束另一种是执行计划走了全表扫描导致锁范围过大这就要给外键列补索引了并在业务低峰期执行。我强烈建议对生产库里所有加了外键的表做一次体检检查外键列是否有索引、事务平均时长是多少、有没有超长事务在运行。把这些问题在“出事之前”暴露出来远比半夜接到告警再去数据库折腾要舒服得多。5.3 级联删除不小心误删了一大片怎么防范ON DELETE CASCADE 是一把双刃剑用好了省心用不好就是事故导火索。我见过一次比较严重的线下删数据事故运营人员本来只想删一条发布信息结果这个发布会连带删除它的所有评价、点赞、浏览记录、附件记录因为相关的表全部设置了级联删除最终删掉了十几万行数据。要防范级联删除误伤最稳妥的办法是评估你的业务到底有没有必要使用 CASCADE。如果孩子数据真的需要跟着父数据一起消失那可以用但删除动作必须经过严格的审批和数据量预估。如果孩子数据的价值比较高我建议改成 RESTRICT让开发人员在应用层显式控制删除顺序先删子表再删父表每一步都有人为确认。如果已经用了 CASCADE还有一种折中的保护手段不要在生产环境用 DELETE 物理删除而是给表增加一个 deleted 状态字段。所有业务删除都走 UPDATE 把状态改成已删除外键约束依然存在但 CASCADE 不会被触发历史数据完整保留。这个做法对业务透明又能在关键时刻保住数据是很多团队实际采用的方案。5.4 临时删除外键约束做完数据操作再重建有些数据迁移场景下你必须临时移除外键约束比如把一个大表从旧库搬到新库、重建索引、或者导入海量清洗后的数据。这时候的操作要谨慎我一般按下面的顺序从库里导出完整的外键定义 SQL保存到变更记录里。记录当前外键涉及的子表行数、父表行数用作操作基线。执行 ALTER TABLE DROP FOREIGN KEYMySQL或 ALTER TABLE DROP CONSTRAINTPostgreSQL。完成数据搬运或清洗。重建外键约束并执行一致性校验。PostgreSQL 里删除外键的语法是ALTER TABLE orders DROP CONSTRAINT fk_orders_customer;MySQL 则是ALTER TABLE orders DROP FOREIGN KEY fk_orders_customer;重建约束的 SQL 不能再手敲一遍旧脚本了直接用刚才导出备份的定义避免漏掉策略参数。重建完成后我还会顺手跑一遍 LEFT JOIN 反查确认没有生成新的孤儿数据。这一步不能省我有一次就因为重建时把 ON DELETE 策略写错了导致后续清理数据时行为完全不对花了一个晚上才把对账数据修回来。5.5 高频外键问题速查表现象可能原因排查与解决插入数据报外键冲突外键值在父表不存在或类型/字符集不匹配反查父表记录比对字段定义修正写入值加外键时报错表中已有孤儿数据或字段类型不一致先跑 LEFT JOIN 反查修完脏数据再 ALTER删除父表记录卡死子表外键列无索引或存在长时间未提交事务查看锁等待给子表加索引结束长事务级联删除删了大量意外数据ON DELETE CASCADE 策略过于激进改为 RESTRICT或业务层使用软删除外键约束失效但没有报错执行了 FOREIGN_KEY_CHECKS0 后忘记恢复恢复开关核查开关关闭期间写入的数据分库分表后外键无法使用物理上跨了多个数据库实例应用层校验 定期对账 归档库补外键排查外键问题最大的痛苦往往不是技术本身而是你不知道问题发生在哪一层。所以我特别建议每个团队都准备一份建表规范哪些表必须有外键、外键策略怎么定、外键列必须建索引、变更外键需要走什么审批流程。把这些规则前置到开发阶段能让后续的运维轻松非常多。我在实际项目中最大的体会是外键不是一个“加了就完事”的功能它的设计、验证和维护必须是一个持续的过程。每张表的外键策略都值得反复问一遍“这个引用关系在业务上意味着什么”搞清楚之后再决定是级联、置空还是拒绝。最后再分享一个小技巧如果你决定在某些表上不使用外键一定要写一个定时巡检脚本每天查一遍孤儿数据并生成报告。这个脚本的成本很低但在关键时刻能帮你兜住数据质量比出了事故再手工清数据强一百倍。
坑你了)
