外键操作卡表的根本原因是子表外键列未建最左前缀索引，导致InnoDB全表扫描并升级行锁为事实上的表锁；ON DELETE CASCADE会进一步扩大锁范围，应改用业务层分步删除。
外键操作为什么会让整个表卡住
MySQL 在执行涉及外键的 DML（如 INSERT、UPDATE、DELETE）时，会对**被引用表（父表）的关联索引记录加 LOCK_S（共享锁）**，同时对**当前表（子表）的外键字段值对应行加 LOCK_X（排他锁）**。这不是“整张表锁死”，但一旦父表上缺少对应索引，InnoDB 就会退化为全表扫描 + 行锁升级，看起来像锁表。
- 典型现象：
DELETE FROM parent WHERE id = 1卡住，同时SHOW ENGINE INNODB STATUS显示大量waiting for table metadata lock或lock wait timeout exceeded - 根本原因：子表外键列没建索引 → InnoDB 无法快速定位依赖行，只能扫全表并逐行加锁
- 影响范围：不只是 DELETE，
UPDATE parent.id和INSERT INTO child同样触发，只要涉及外键列比对
外键列必须加索引，但不是随便加
加索引不是为了查询快，而是为了让 InnoDB 能用索引定位依赖行、避免全表扫描锁。但索引结构有讲究——外键列必须是索引的**最左前缀**，且不能只是组合索引里的中间或末尾列。
- ✅ 正确：
ALTER TABLE child ADD INDEX idx_fk_parent_id (parent_id)或ADD INDEX idx_composite (parent_id, status) - ❌ 无效：
ADD INDEX idx_wrong (status, parent_id)——parent_id不在最左，InnoDB 无法使用该索引加速外键检查 - ⚠️ 注意：主键或唯一索引自带索引效果，但如果外键指向的是
PRIMARY KEY，子表仍需自己建索引；InnoDB 不复用父表索引
ON DELETE CASCADE 的锁行为更隐蔽
ON DELETE CASCADE 看似省事，实则锁范围更大：父表一行删除，会触发子表所有匹配行的级联删除，每条子行都要走外键检查 + 加锁流程，还可能引发二级索引维护开销。
- 风险点：子表数据量大时，
DELETE FROM parent WHERE id = X可能长时间持有父表记录锁，并阻塞其他事务访问该父记录 - 性能陷阱：级联删除不走批量优化，是逐行处理，容易触发
lock wait timeout - 替代建议：业务层分步删（先查子表 ID，再批量删子表，最后删父表），可控性更高，锁粒度更小
如何验证外键是否正在导致锁冲突
别猜，直接看 InnoDB 的实时锁视图。关键看三张表：information_schema.INNODB_TRX（当前事务）、INNODB_LOCKS（已加锁）、INNODB_LOCK_WAITS（谁等谁）。
- 快速定位：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60找运行超 1 分钟的事务 - 查锁等待：
SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_query FROM information_schema.INNODB_LOCK_WAITS w INNER JOIN information_schema.INNODB_TRX b ON b.trx_id = w.blocking_trx_id INNER JOIN information_schema.INNODB_TRX r ON r.trx_id = w.requesting_trx_id - 重点字段：
trx_query中是否含INSERT/UPDATE/DELETE外键列，blocking_query是否在操作父表或子表外键索引
外键锁问题最难缠的地方不在语法，而在它藏在正常 DML 后面、不报错、只变慢；一旦父表没索引或子表数据倾斜，锁就从“行级”悄悄变成“事实上的表级”。上线前务必用真实数据压测外键路径，别只看 DDL 是否成功。
