外键级联不触发的主因是存储引擎非innodb（myisam忽略外键）或外键定义缺失on delete cascade（默认restrict），需通过show create table和information_schema确认引擎及级联规则，并修复引擎、重建外键约束。
外键级联操作报错，90% 是约束未生效或级联定义缺失，不是 MySQL 8.0 的 bug。
为什么 SHOW CREATE TABLE 看起来有外键，但 ON DELETE CASCADE 就不触发？
MySQL 只在 InnoDB 引擎下执行外键约束，MyISAM 表即使语法正确也完全忽略。升级后如果某张表被意外转成 MyISAM（比如通过 mysqldump --no-create-options 导入、或手动执行过 ALTER TABLE t ENGINE=MyISAM），外键就形同虚设。
检查方式：
- 运行
SHOW CREATE TABLE child_table;，确认输出里明确包含ENGINE=InnoDB - 执行
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'child_table';，结果必须是InnoDB - 若引擎不对，立刻修复：
ALTER TABLE child_table ENGINE=InnoDB;（注意：该操作会锁表，线上慎用）
删父记录时报 ERROR 1451，但明明写了 ON DELETE CASCADE
这说明外键定义里根本没写 ON DELETE CASCADE，而是用了默认的 RESTRICT 或 NO ACTION。MySQL 升级不会自动补全级联行为，旧表上的外键仍是升级前的状态。
排查与修复步骤：
- 查当前外键定义：
SELECT CONSTRAINT_NAME, UPDATE_RULE, DELETE_RULE FROM information_schema.KEY_COLUMN_USAGE kcu JOIN information_schema.REFERENTIAL_CONSTRAINTS rc ON kcu.CONSTRAINT_NAME = rc.CONSTRAINT_NAME WHERE kcu.TABLE_NAME = 'child_table'; - 若
DELETE_RULE是RESTRICT，说明没开级联 - 重建外键（必须先 DROP 再 ADD）：
ALTER TABLE child_table DROP FOREIGN KEY fk_name;，然后ALTER TABLE child_table ADD CONSTRAINT fk_name FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE ON UPDATE CASCADE; - 注意：
fk_name必须和SHOW CREATE TABLE中显示的一致，不能凭空猜测
级联删除卡住、慢、甚至死锁，怎么定位？
级联不是“自动优化”的操作。它本质是单事务内按依赖链顺序执行多条 DELETE，子表若无索引、数据量大、或存在多层嵌套（如 orders → order_items → logs），就会放大锁持有时间和扫描成本。
关键检查点：
- 外键列是否已有索引？MySQL 要求外键列必须有索引（否则建表失败），但复合查询条件（如
WHERE order_id = ? AND status = 'pending'）仍可能走全表扫描 —— 运行EXPLAIN DELETE FROM order_items WHERE order_id = 123;确认是否命中索引 - 是否存在多层级联？例如
users → orders → order_items → inventory_logs，删一个用户可能触发数万行删除。用SELECT COUNT(*)逐层估算影响范围，别等执行时才发现 - 检查
INFORMATION_SCHEMA.INNODB_TRX和INFORMATION_SCHEMA.INNODB_LOCK_WAITS，确认是否因锁等待导致阻塞
升级后外键突然“失效”，但没报错
常见于跨大版本升级（如 5.6 → 8.0）后，FOREIGN_KEY_CHECKS 被意外置为 0 并残留。此时所有外键校验被跳过，INSERT/UPDATE/DELETE 都不会触发约束，也不会报错，但数据完整性已失控。
立即验证：
- 执行
SELECT @@foreign_key_checks;，预期返回1；若为0，马上执行SET FOREIGN_KEY_CHECKS = 1; - 检查 MySQL 启动配置文件（如
/etc/my.cnf），确认没有foreign_key_checks = 0这类持久化设置 - 对关键外键表做一次强制校验：
ALTER TABLE child_table ENGINE=InnoDB;—— 此操作会重建表并重新校验外键引用关系
真正危险的不是报错，而是静默失效。升级后务必把 @@foreign_key_checks 和 ENGINE 两项纳入上线核对清单，漏掉任何一个，后续的数据问题都很难回溯。
