1. 先把 MySQL 外键约束这回事说透
只要做过几年业务库的人，几乎都在评审会上被问过一句：“这张表要不要加 MySQL 外键约束？”支持的一方说数据一致性必须有兜底，反对的一方甩出“高并发下会死锁”“分库分表用不了”。两边说的都对，但都对得不完整。外键约束（FOREIGN KEY）本质上是把一条跨表的引用完整性规则交给数据库引擎去强制执行——子表里出现的每一个引用值，必须在父表里真实存在；父表里被引用的行，在被删除或改键之前，必须先处理好子表里的引用。这句话听起来简单，落到 InnoDB 的存储引擎、锁管理器和数据字典里，就会衍生出一连串工程上的连锁反应：索引要求、加锁范围、DDL 限制、迁移工具兼容性、分片方案冲突。
这篇内容想干的事情很具体：把 MySQL 外键约束从“语法怎么写”一路讲到“生产上该不该用、用了之后怎么排障”。适合三类人看——刚学完建表语句想搞懂报错的新手、正在给存量系统做数据库规范的中级开发、以及被外键引发的死锁和迁移失败折腾过、想系统复盘的同学。文中涉及的验证过程都基于 InnoDB 引擎的常规行为，MySQL 5.7 与 8.0 在细节上有差异的地方我会单独标出来，这些差异恰恰是最容易踩坑的地方。
1.1 从一条脏数据说起：外键真正解决的三个问题
先别急着谈性能，回到外键存在的初衷。假设有一个订单明细表order_item，每行都带一个order_id指向订单主表orders。如果没有外键约束，代码里任何一处漏判、任何一次手工修数据、任何一个跑了一半就崩掉的批处理，都可能往明细表里塞进一个父订单根本不存在的孤儿行。这种数据不会立刻报错，它会安静地躺在库里，直到某天报表对不上账、某个接口查详情时返回空对象，排查起来要顺着时间线倒推好几天。
外键约束在数据库层面干的第一件事，就是堵住写入侧的孤儿行。插入或更新子表时，引擎会去父表确认引用值存在，不存在就直接拒绝（错误码 1452）。第二件事是堵住删除侧的悬挂引用——父表的行被删掉后，子表还指着它，这就是悬挂引用，引擎会按你声明的行为（拒绝、级联删除、置空）处理（错误码 1451）。第三件事比较隐蔽，是给数据模型加了一份可执行的文档：表与表之间的从属关系不再只存在于 ER 图和口口相传里，而是写进了数据字典，任何新接入的人执行一句SHOW CREATE TABLE就能看到谁依赖谁，级联行为是什么。
第三条价值经常被低估。我见过不止一个系统，表之间的引用关系只活在几位老员工的记忆里，人一走，删数据就变成了拆炸弹。外键约束把这份记忆固化下来了，哪怕是坏消息（比如发现某张表被七张表引用），也早发现早好。
不过要清醒一点：外键只保证引用完整性，它管不了业务语义。比如订单明细引用的订单确实存在，但那可能是别人的订单、可能是已取消的订单、可能金额对不上。这些都得靠应用层校验、靠状态机、靠权限控制。外键是地基，不是承重墙，别指望它把业务规则一起包了。
1.2 InnoDB 是怎么把外键"落地"的
理解实现细节，后面所有的性能问题和报错才有解释的落点。InnoDB 对外键的支持不是"检查一下存在性"这么轻量，它在数据字典里维护了父子关系的元数据，并且在子表的外键列上强制要求一个索引。这个索引不是可选项——如果建表时子表该列没有可用索引，InnoDB 会自动创建一个，索引名默认与约束名一致。为什么要索引？因为父表删除或更新键值时，引擎必须快速找到子表里所有引用该值的行，没有索引就只能全表扫，这在生产环境是不可接受的。
父表那一侧也有要求：被引用的列必须是最左前缀可用的索引，通常就是主键或唯一键。引擎需要在父表索引上定位到被引用的那一行，才能加锁做检查。这就解释了那个经典的报错 1822：Failed to add the foreign key constraint. Missing index for constraint——父表的被引用列没索引，或者子表列没有可用索引（自动创建失败的情形，比如列类型不匹配）。
检查时机也值得说清楚。外键检查发生在语句执行的行级操作阶段，不是提交阶段。也就是说，插入子表行的那一刻就要去父表验证，验证过程需要对父表对应索引记录加共享锁（S 锁）。这个锁一直持有到事务结束。这就是外键在高并发下最核心的性能争议点：一次子表插入，实际涉及两张表的加锁，锁的持有时间被拉长到整个事务周期。MySQL 从 5.6 开始对父表加锁做了优化，多个事务同时插入引用同一父行的子行时，S 锁之间是兼容的，可以并发获取，所以单纯"很多事务插子表"并不会互相阻塞。真正会阻塞的是"有人在改父表那一行"——那时需要 X 锁，跟一堆 S 锁正面冲突。
还有一个容易被忽略的点：MySQL 的外键检查是立即生效的，不支持标准 SQL 里的DEFERRABLE INITIALLY DEFERRED延迟约束。这意味着你不能在一个事务里先插子表再插父表然后指望提交时才校验，顺序错了当场报错。做数据迁移、批量灌数的时候，这个约束会逼着你严格排序，或者临时关掉检查。
1.3 为什么很多团队最终选择不用外键
讲完机制，就得面对现实。互联网业务库普遍不用物理外键，原因不是"外键不好"，而是几笔明确的账算不过来。
第一笔是分库分表的账。一旦订单表按用户 ID 拆到多个实例，父表和子表很可能落在不同的库甚至不同的物理机，跨库外键在 MySQL 里根本不支持。这时候引用完整性只能上移到应用层，或者靠定时对账任务兜底。既然终局方案是逻辑外键，很多团队从第一天就不引入物理外键，避免后期拆除的迁移成本。
第二笔是在线 DDL 和迁移工具的账。物理外键会让一批运维手段失效或者变复杂。比如用影子表做在线表结构变更的工具，遇到外键需要额外处理策略，稍不注意就会把子表的外键指向影子表或者直接丢约束。再比如逻辑备份恢复，必须先关掉FOREIGN_KEY_CHECKS再按依赖顺序导入，否则中途报错中断。这些都不是不可解，但每次都要专门处理，出错概率累积起来很可观。
第三笔是锁竞争的账。核心交易表的 QPS 一旦上去，父表上任何一次更新或删除都可能被大量子表插入的 S 锁拖住，形成排队。尤其是那种"父表单行对应几十万子行"的场景，删除父行时要扫子表索引、逐行加锁、逐行级联，长事务几乎是必然的。
我的判断标准比较朴素：数据一致性要求极高、并发不高、单库不拆分的系统，物理外键是划算的，比如内部管理后台、配置中心、财务凭证类库、中小型 SaaS 的租户库。核心链路、高并发、明确要分片的系统，用逻辑外键 + 应用层校验 + 定期对账更务实。最怕的是骑墙：建了外键又在代码里重复校验一遍，或者建了外键却天天靠SET FOREIGN_KEY_CHECKS=0绕过去，那就是纯负担。
2. 建表前的硬性条件清单：不满足这些，外键根本建不起来
报错 1215（Cannot add foreign key constraint）和 1005（errno 150）是新手最常见的一对，信息量极低，几乎不告诉你原因。实际上这类报错背后有固定的十几个可能原因，逐条排查能覆盖九成以上场景。这一章把前提条件拆开讲清楚，后面建表就不会反复试错。
2.1 五条硬性前提逐条拆解
引擎必须是 InnoDB。MySQL 8.0 已经把 MyISAM 的系统表替换掉了，但用户表仍可能选错引擎。MyISAM 完全不支持外键，建表时写了FOREIGN KEY会被静默忽略——注意是忽略，不是报错，这比报错更坑，你以为建上了其实没建。养成习惯，建完表执行SHOW CREATE TABLE确认约束真的存在。
列的"相似性"要求。这是最容易翻车的一条，官方措辞是"similar data types"，具体规则分三类：整数类型必须大小相同且符号相同（INT和INT UNSIGNED不兼容，BIGINT和INT不兼容）；字符串类型长度可以不同，但字符集和排序规则必须一致（utf8mb4_0900_ai_ci对utf8mb4_general_ci就是不行）；二进制字符串的长度和类型都得一致。MySQL 8.0 对这类不匹配给出了更清晰的 3780 错误，5.7 上则统一塞进 1215。
父表被引用列必须有索引，且是最左前缀。主键天然满足。如果引用的是普通列，得先给它建索引或唯一索引。注意"最左前缀"这几个字：复合索引(a, b)可以支撑引用a，但不能支撑单独引用b。
子表列要有可用索引。没有的话 InnoDB 会自动建一个。这里有个细节：自动建的索引不会因为你后来DROP FOREIGN KEY而消失，得手动DROP INDEX，否则会留下一堆没人认识的索引，这个坑我在做索引治理时踩过好几次。
不能用在临时表和分区表上。临时表不支持外键是明确限制；InnoDB 分区表也不支持外键，这一点在规划大表分区方案时一定要提前确认，不然后期想分区就得先拆外键。
除了这五条，还有两个环境级开关值得记住：foreign_key_checks会话变量可以临时关闭检查（导入数据、批量修复时用），innodb_foreign_key_checks不是变量，别记混。关闭检查只影响校验，不影响约束定义，恢复后存量数据如果本来就不合法，后续操作照样会撞上。
2.2 索引为什么是刚需：从加锁范围反推
很多人把"子表外键列要有索引"当成一条死记硬背的规则，其实从加锁逻辑推一遍就再也不会忘。
考虑父表删除一行的过程：引擎要在子表里找出所有order_id = 123的行，逐个按ON DELETE规则处理。有索引时，这是一次索引范围扫描，命中的行加行锁，范围之外的记录不碰。没索引时，只能全表扫，扫描过程中经过的每一行记录都可能被加上锁（取决于隔离级别和索引情况，RC 下会释放不匹配的行锁，RR 下更麻烦）。一张千万行的子表，删一行父表数据锁住一大片，其他事务直接堵死。
所以那条规则的真实含义是：索引把外键检查的代价从 O(N) 降到了 O(log N + 命中行数)，同时把加锁范围从全表收敛到了具体记录。这也是为什么"外键列一定要有索引"和"外键列索引选择性不重要"可以同时成立——它服务的不是查询，是约束检查的定位效率。
顺带提一句复合外键。声明FOREIGN KEY (a, b) REFERENCES parent(x, y)时，子表索引必须以(a, b)这个顺序开头，父表索引必须以(x, y)开头，列的顺序不能对调。这种写法在多租户系统里很实用，比如子表带tenant_id，外键写成(tenant_id, user_id)，既满足约束又顺便支撑了租户维度的查询。
2.3 命名规范与几个特殊写法
外键的约束名建议显式指定，别用自动生成的表名_ibfk_1。自动名在你删了重建之后会变，脚本里硬编码就容易失效。命名上我习惯用fk_子表_父表_列名这种能自解释的格式，比如fk_order_item_orders_order_id，出问题时从错误日志里一眼能看出是哪条约束。
自引用外键（树形结构）也常见，比如分类表的parent_id指向自己的id：
CREATE TABLE category ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, parent_id BIGINT UNSIGNED NULL, name VARCHAR(64) NOT NULL, PRIMARY KEY (id), KEY idx_parent (parent_id), CONSTRAINT fk_category_parent FOREIGN KEY (parent_id) REFERENCES category (id) ON DELETE RESTRICT ) ENGINE=InnoDB;自引用要特别小心ON DELETE CASCADE。理论上它能实现"删父节点连带删整棵子树"，但深度大的树会形成一条很长的级联链，每层都加锁，事务又长又重，还容易撞上锁等待超时。我的做法是自引用一律RESTRICT，删除逻辑放到应用层按层处理，可控性高得多。
3. 完整实操：从零搭一套带外键的订单模型
理论说完了，动手跑一遍最实在。下面这套模型很小，但把外键的四种行为、复合索引、自引用都覆盖到了，可以直接拿去本地库跑。
3.1 建表与 DDL 逐行解释
-- 父表：订单 CREATE TABLE orders ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, status TINYINT NOT NULL DEFAULT 0, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci; -- 子表：订单明细 CREATE TABLE order_item ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, order_id BIGINT UNSIGNED NOT NULL, sku_id BIGINT UNSIGNED NOT NULL, qty INT NOT NULL, PRIMARY KEY (id), KEY idx_order_id (order_id), CONSTRAINT fk_item_order FOREIGN KEY (order_id) REFERENCES orders (id) ON DELETE CASCADE ON UPDATE RESTRICT ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;逐行说几个关键决策。id用BIGINT UNSIGNED，那么子表的order_id必须是完全相同的类型，写INT UNSIGNED或BIGINT（带符号）都会报 3780。字符集排序规则两边显式写成一样的，避免继承不同库级默认值导致不匹配。idx_order_id是手动建的，虽然引擎会自动补一个，但手动建的好处是能自己控制索引名，将来做索引审查时不会看到一堆fk_item_order这种名字搞不清用途的索引。
ON DELETE CASCADE配合ON UPDATE RESTRICT是我对订单模型的默认选择：订单删了明细没有存在意义，级联删合理；但订单主键是自增的，正常情况下永远不该被更新，所以更新行为设成拒绝，一旦有人写错 SQL 去改主键，立刻报错暴露问题。
验证建表结果：
SHOW CREATE TABLE order_item\G输出里能看到CONSTRAINT fk_item_order这一段，才算真的建上了。再查一下自动索引有没有重复：
SELECT index_name, column_name, seq_in_index FROM information_schema.statistics WHERE table_schema = DATABASE() AND table_name = 'order_item';3.2 四类级联行为实测记录
四种行为必须在真实环境验证一遍，光看文档记不住。下面是我在本地 8.0 实例上的实测结果整理。
| 行为 | 删除父行时 | 更新父行键值时 | 适用场景 | 关键限制 |
|---|---|---|---|---|
| RESTRICT | 有子行则拒绝（1451） | 有子行则拒绝 | 强从属但需人工确认 | 默认值，无需显式写 |
| NO ACTION | 同 RESTRICT | 同 RESTRICT | 标准 SQL 写法 | MySQL 中等价于 RESTRICT，不延迟 |
| CASCADE | 级联删除所有子行 | 级联更新子行引用值 | 强从属、生命周期一致 | 级联链长时事务很重 |
| SET NULL | 子行外键列置 NULL | 同左 | 弱从属、可选关联 | 子表列必须允许 NULL |
实测时有个细节值得注意：SET NULL如果子表列声明成NOT NULL，建表阶段就会报错，不会等到运行时才告诉你。这个约束是 DDL 期检查的，属于"早失败"的好设计。
另外，NO ACTION在 MySQL 里跟RESTRICT完全等价，都是立即检查，跟 PostgreSQL 那种可以延迟到事务提交的NO ACTION不是一回事。从别的数据库迁过来的同学在这一点上很容易想当然。
批量测试脚本大致长这样，跑完看每一步的报错码就能对上号：
START TRANSACTION; INSERT INTO orders (order_no) VALUES ('T2024001'); SET @oid = LAST_INSERT_ID(); INSERT INTO order_item (order_id, sku_id, qty) VALUES (@oid, 1001, 2); COMMIT; -- 触发级联删除，先看子表行数 SELECT COUNT(*) FROM order_item WHERE order_id = @oid; DELETE FROM orders WHERE id = @oid; SELECT COUNT(*) FROM order_item WHERE order_id = @oid; -- 应为 0 -- 验证孤儿行拦截 INSERT INTO order_item (order_id, sku_id, qty) VALUES (99999999, 1001, 1); -- ERROR 1452 (23000): Cannot add or update a child row3.3 给存量表补外键：算法选择与踩坑
线上已经有数据的表要补外键，比新建表麻烦得多。核心问题在于 MySQL 8.0 里ALTER TABLE ... ADD FOREIGN KEY的算法选择跟foreign_key_checks直接挂钩：当检查开启时，加外键会走 COPY 算法，整表重建并且阻塞写入；把会话的foreign_key_checks设为 0 之后，才能用ALGORITHM=INPLACE完成。这个细节文档里有，但很容易看漏。
所以稳妥流程是这样的：
-- 1. 先在从库或影子库上验证存量数据是否干净 SELECT i.order_id FROM order_item i LEFT JOIN orders o ON o.id = i.order_id WHERE o.id IS NULL LIMIT 100; -- 2. 线上执行，显式指定算法 SET SESSION foreign_key_checks = 0; ALTER TABLE order_item ADD CONSTRAINT fk_item_order FOREIGN KEY (order_id) REFERENCES orders (id) ON DELETE CASCADE, ALGORITHM = INPLACE, LOCK = NONE; SET SESSION foreign_key_checks = 1;第一步的反连接查询是必须的。存量数据里只要有一行孤儿，加约束就会失败，而在大表上这个失败可能是在跑了十几分钟之后才报出来的，代价很高。先用LIMIT 100抽样确认有没有问题，有的话先清理或补齐再动手。
注意：
foreign_key_checks = 0期间加进去的不合规数据不会被追溯校验。所以关检查加约束这个操作，本质上是用"我相信存量数据是干净的"换取不停机。生产上要么先跑全量校验任务，要么在低峰期做并预留回滚方案。
删除外键也有个顺序问题。ALTER TABLE ... DROP FOREIGN KEY 约束名只删约束，不动索引。如果那个索引是当初为外键自动创建的、没别的用途，需要再补一句DROP INDEX。查哪些索引是孤儿索引，可以对比information_schema.statistics和innodb_sys_foreign（8.0 里是information_schema.INNODB_FOREIGN系列表，需要先开innodb_stats相关开关）。我通常的做法是简单点：直接把表的所有索引列出来，逐个问"这个索引支撑哪条查询"，问不出用途的就可以考虑删。
4. 生产环境里的外键：性能、锁与死锁
到这一章才是真正让人头疼的部分。前面建表报错大不了多看几遍文档，改成锁等待超时和死锁就得靠经验了。这部分内容我会把机制和现象对着讲，方便你线上排查时快速定位。
4.1 外键检查到底加了什么锁
先给结论：子表写入时，对父表被引用索引记录加共享锁（S 锁）；父表删除或更新键值时，对子表匹配记录加锁并按级联行为处理。这两条是所有外键锁问题的根。
第一个结论的推论前面提过：多个事务同时插子表、引用同一个父行，S 锁互相兼容，不会阻塞。这打破了"用外键就一定高并发写不进去"的迷思。真正会出问题的是混合负载——一边有大量子表插入（持有父行 S 锁），另一边有人去更新或删除那个父行（需要 X 锁）。这时 X 锁要等所有 S 锁释放，而后面的新 S 锁请求又会插到 X 锁前面或后面，取决于锁队列策略，最坏情况就是排队时间越来越长。
第二个结论的推论更危险：ON DELETE CASCADE的删除是逐行进行的。删一行父表数据、级联删掉十万行子表数据，这十万行每一行都要加锁、写 undo、写 redo，整个操作在一个事务里完成。这不只是慢，undo 空间会暴涨，主从延迟会拉大，锁等待会传染到整条链路。我见过一个案例，运营在后台点了一次"删除活动"，活动关联了两百多万条参与记录，删除请求跑了四十分钟，期间整张参与表基本不可写。
对应的处理办法有几条：大批量删除不要依赖数据库级联，改成应用层分批删子表、再删父表；必须保留级联的话，给删除操作加单次行数上限（分批提交，每批 500 到 1000 行）；再激进一点，把级联改成RESTRICT，让数据库只负责拦住，删多少、怎么删由业务代码控制。
查看外键相关的锁等待，performance_schema.data_locks（8.0）或者information_schema.innodb_locks（5.7）能直接看到等待关系。重点关注LOCK_MODE为S且LOCK_TYPE是RECORD的记录，以及BLOCKING_TRX_ID指向谁。
4.2 死锁的典型形态与规避手法
外键引发的死锁有几种固定套路，认出来就不慌了。
第一种：父子表操作顺序不一致。事务 A 先更新父表再插入子表，事务 B 先插入子表再更新父表。A 持父行 X 锁等子表锁，B 持子表锁等父行 X 锁，闭环。这种死锁跟外键无关的版本也很常见，但外键让它更容易触发，因为子表插入会隐式去拿父表 S 锁——这条隐式加锁路径在代码 review 时几乎看不见。
规避办法很土但有效：约定全局的加锁顺序，永远先父后子。所有涉及两张表的写事务，都按"父表 → 子表"的顺序操作。这条规则写进团队规范，能干掉大部分这类死锁。
第二种：级联删除的交叉。两个事务分别删父表的两行，各自的行在子表里有交叉引用（比如子表同时引用了两个父表），双方都在等对方释放子表行锁。这种情况比较少见但确实存在。
第三种：间隙锁叠加。RR 隔离级别下，子表外键索引上的范围操作可能带间隙锁，跟其他事务的插入意向锁冲突。这类死锁的排查要结合SHOW ENGINE INNODB STATUS里LATEST DETECTED DEADLOCK段落的完整信息看，光看应用日志是看不出所以然的。
排查死锁我一般按这个顺序走：先拿SHOW ENGINE INNODB STATUS看最近一次死锁的两个事务分别执行了什么 SQL、持有什么锁、等待什么锁；再对照代码找出两条事务路径；最后判断是加锁顺序问题、锁范围问题还是事务过长问题。如果是事务过长，看看能不能把非数据库操作（调外部接口、发消息）挪到事务外面。
innodb_deadlock_detect默认开着，检测到就回滚代价小的那个事务。如果死锁频率很高，别急着关检测，先治根因——关掉检测只是把死锁变成锁等待超时，问题还在，只是从快速失败变成了慢速失败。
4.3 大表、分片与归档场景下的取舍
规模上去之后，外键的账要重新算。
分库分表场景，物理外键直接出局。父表和子表落在不同分片是常态，跨库外键 MySQL 不支持。这时候正确的姿势是：表结构上不建外键，但把引用关系写进设计文档和代码约束层；写入前做一次存在性校验（可以走缓存，不一定每次查库）；再加一个离线对账任务，每天扫一遍孤儿行并告警。这套组合拳的可靠性不比物理外键差，代价是多了代码和一个定时任务。
历史归档场景要特别注意。归档老订单时，如果明细表有ON DELETE CASCADE，删除父行的瞬间归档数据就跟着没了，这是灾难性的。归档逻辑必须显式按顺序处理：先归档明细、再归档主表，全程不触发级联。更稳妥的做法是归档表专门设计成不带外键的结构，跟线上表的约束解耦。
在线 DDL 工具兼容性。影子表方案在遇到带外键的表时需要额外参数来处理外键，处理不当的后果是把外键指向影子表，或者干脆丢掉约束。做这类变更前，务必在预发环境完整演练一遍，并用SHOW CREATE TABLE前后对比，确认约束数量和指向都没变。
逻辑外键的补偿设计。一旦放弃物理外键，就得在三个地方补：写入路径的存在性校验（同步，可加缓存）、删除路径的引用检查（同步，或改成软删除规避）、定期对账（异步，扫孤儿行和悬挂引用）。这三层里，软删除其实是个很好用的缓冲——不做物理删除，悬挂引用的问题直接消失，代价是每张表都要带deleted_at并且在所有查询里过滤，这个成本要提前算进规范里。
5. 常见问题速查与排查实录
这一章是我自己整理的一张速查表，加上几个印象深刻的排查过程。报错码对上了，基本能直接定位到原因。
5.1 报错码对照表与排查路径
| 错误码 | 报错信息关键词 | 高频原因 | 排查动作 |
|---|---|---|---|
| 1215 | Cannot add foreign key constraint | 类型不匹配、引擎不对、被引用列无索引、字符集不同 | 逐列比对SHOW CREATE TABLE两边输出 |
| 1005 | errno 150 | 与 1215 同源，早期版本的外层包装 | 同上，先解决 1215 的原因 |
| 1451 | Cannot delete or update a parent row | 子表存在引用，且行为是 RESTRICT/NO ACTION | 查子表关联行数，确认是否该级联 |
| 1452 | Cannot add or update a child row | 插入的引用值在父表不存在 | 核对数据来源，检查是否有并发删除 |
| 1822 | Missing index for constraint | 父表被引用列无索引，或子表索引创建失败 | 补索引后重试 |
| 3780 | Referencing column and referenced column are incompatible | 类型/符号/字符集/排序规则不一致 | 用ALTER TABLE MODIFY对齐类型 |
| 3730 | Cannot drop table referenced by a foreign key | 删父表时子表还在引用 | 先删外键再删表，或用SET FOREIGN_KEY_CHECKS=0 |
用 1215 举例说排查方法。它不告诉你具体原因，但你可以主动缩小范围：先把建表语句拆开，单独建父表、单独建子表（不带外键），都成功了再ALTER TABLE ADD CONSTRAINT，这时候报错会精确到约束级别。然后逐项核对：引擎是否都是 InnoDB、列类型是否完全一致（含 UNSIGNED）、字符集排序规则是否一致、父表被引用列有没有索引、是不是分区表。这五项过完，1215 基本就解了。
再看 1452，这个报错在实际业务里经常不是代码 bug，而是并发时序问题：事务 A 插入子表行引用了订单 123，同时事务 B 刚把订单 123 删了。A 检查时父行还在，等它真要拿锁时已经被删，于是报错。这类问题的解法不是加外键，而是调整业务逻辑——删除订单前先确认没有进行中的写入，或者用软删除代替物理删除。
5.2 线上应急：如何安全地摘掉一个外键
假设线上某个外键引发了持续的锁等待，需要紧急处理。步骤得清楚，别慌乱中把表锁死。
第一步，确认锁等待确实跟这个外键有关。查performance_schema.data_locks和data_lock_waits，看阻塞链的头部是不是在子表的外键索引或者父表的被引用索引上。别凭感觉动手。
第二步，评估摘掉外键的影响。这个约束是不是唯一的一致性保障？应用层有没有校验？摘掉之后多久会出问题？如果答案是"没有其他保障"，那摘掉外键只是把数据库层的报错换成了脏数据，得同时准备补偿方案。
第三步，执行。ALTER TABLE ... DROP FOREIGN KEY是 INPLACE 操作，一般不阻塞读写，风险可控。但要注意，如果这个约束的索引是自动创建的，删完约束后索引还在，需要单独评估要不要一起删。
第四步，观察。摘掉之后看锁等待是否消失、慢查询是否恢复。如果问题依旧，说明根因不在外键，得回头重新排查。
注意：紧急操作一定要留记录。哪个外键、什么时候摘的、为什么摘、计划什么时候恢复，写进变更单。我见过摘掉之后忘了恢复的，半年后做数据审计发现一批孤儿行，溯源到这次操作，非常被动。
5.3 几个踩过的坑与实操心得
坑一：以为SHOW CREATE TABLE里有 FOREIGN KEY 就一定生效。MyISAM 表上写的外键会被静默忽略，输出里也不会显示。但如果你从别的地方复制了一段建表语句、忘了改引擎，就会得到一张"看起来有约束"的表。经验是：建完表一定跑一次实际插入测试，插一个不存在的引用值，看是否报 1452。报错才是真的建上了。
坑二：用mysqldump恢复时被外键卡住。默认导出的脚本按字母序建表，子表可能先于父表，导入直接失败。正确做法是导出时加--single-transaction之外，还要在导入前把SET FOREIGN_KEY_CHECKS=0加到脚本头部，导入完成后再置回 1。或者干脆用--skip-add-drop-table配合按依赖顺序手动排列。这个细节在恢复演练里必须验证一次，别等到真出事才发现脚本跑不通。
坑三：批量修复数据时忘了关检查，一条一条报 1452。修历史脏数据的场景，正确姿势是会话级关闭检查、批量更新、再重新开启，然后跑一遍孤儿行检测确认修干净了。但关检查期间写入的不合规数据不会被拦住，所以这个窗口要尽量短，最好在业务低峰做，最好加个分布式锁防止其他写入进来。
坑四：以为外键能防住"逻辑上的悬挂"。外键只管值存不存在，管不了状态。订单已经status = cancelled，明细照样能插进去，因为订单行还在。这类问题必须靠业务校验，别指望外键。
心得一：把外键当成设计文档而不是性能开关。我现在的做法是，新项目建模阶段允许画外键、写外键，评审时逐个过一遍：这个关系是强从属还是弱引用？强从属用物理外键，弱引用（比如可选的标签、可空的归属）就别建，用应用层校验。这样既能享受外键带来的一致性，又不会把整个库绑死。
心得二：外键索引的命名统一走自己的规范。自动生成的索引名和约束名混在一起，做索引治理时特别痛苦。统一用idx_表_列给索引起名，约束用fk_子父_列，两年后回来看依然清晰。
心得三：给每个外键写一句注释。MySQL 支持约束注释（8.0.16 之后COMMENT子句可用于约束），写清楚"为什么建这个外键、级联行为为什么这么选"。半年后有人想删它，看到注释会先想一下，而不是直接DROP。
最后分享一个我常用的自检 SQL，扫一遍当前库所有外键，连同级联行为和索引情况一起列出来，做数据库规范巡检时很省事：
SELECT kcu.TABLE_NAME AS child_table, kcu.COLUMN_NAME AS child_col, kcu.REFERENCED_TABLE_NAME AS parent_table, kcu.REFERENCED_COLUMN_NAME AS parent_col, kcu.CONSTRAINT_NAME AS fk_name, rc.DELETE_RULE, rc.UPDATE_RULE FROM information_schema.KEY_COLUMN_USAGE kcu JOIN information_schema.REFERENTIAL_CONSTRAINTS rc ON rc.CONSTRAINT_NAME = kcu.CONSTRAINT_NAME AND rc.CONSTRAINT_SCHEMA = kcu.TABLE_SCHEMA WHERE kcu.TABLE_SCHEMA = DATABASE() AND kcu.REFERENCED_TABLE_NAME IS NOT NULL ORDER BY child_table, fk_name;跑出来的结果我一般会重点看两列：DELETE_RULE里有多少个CASCADE（每一个都是潜在的批量删除风险点），以及子表列是否都有对应的索引（用statistics表交叉比对）。这套检查我每个月跑一次，比出事之后再翻数据字典高效得多。
