ON DELETE CASCADE 必须满足四项硬性条件：使用InnoDB引擎、父表被引用列有索引、子表外键列显式建索引、两字段类型严格一致，缺一即失效；建表时直接定义最稳妥，已有表需先加索引再添约束，且执行前须确保数据一致性。
ON DELETE CASCADE 必须满足的硬性条件
不满足这些条件，ON DELETE CASCADE 就是摆设，删父行时子行纹丝不动，还不会报错——你只会发现数据“漏删”了。
-
InnoDB引擎是强制前提：MyISAM 表加了外键语法也无效，MySQL 直接忽略 - 父表被引用列（如
stu.sid）必须有索引，主键自动满足，但唯一键或普通索引也行 - 子表外键列（如
sc.sid）必须显式建索引，FOREIGN KEY语句本身不自动建索引，缺它会创建失败 - 两字段类型必须严格一致：
INT和INT UNSIGNED不兼容，VARCHAR(20)和VARCHAR(25)也不行
CREATE TABLE 时直接定义级联行为
这是最稳妥的做法。ALTER TABLE 补级联容易漏掉索引或类型校验，而建表时一次写全，逻辑清晰、错误前置。
示例中子表 sc 显式声明了 INDEX (sid)，再跟 FOREIGN KEY，顺序不能颠倒：
CREATE TABLE stu ( sid INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, name VARCHAR(20) NOT NULL ) ENGINE=InnoDB CHARSET=utf8; <p>CREATE TABLE sc ( scid INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, sid INT UNSIGNED NOT NULL, score VARCHAR(20) DEFAULT '0', INDEX (sid), -- 必须！否则 FOREIGN KEY 创建失败 FOREIGN KEY (sid) REFERENCES stu(sid) ON DELETE CASCADE ) ENGINE=InnoDB CHARSET=utf8;
注意：ON UPDATE CASCADE 很少用，主键更新在业务中本就该避免；ON DELETE CASCADE 才是日常主力。
已有表补加级联删除的正确顺序
别直接 ALTER TABLE ... ADD FOREIGN KEY ... ON DELETE CASCADE —— 大概率报错 “Error 1005”，根源往往是索引缺失或类型不匹配。
- 先给子表外键列加索引：
ALTER TABLE sc ADD INDEX (sid); - 再加外键约束：
ALTER TABLE sc ADD CONSTRAINT fk_sc_sid FOREIGN KEY (sid) REFERENCES stu(sid) ON DELETE CASCADE; - 如果报错 “Cannot add or update a child row”，说明已有数据违反外键约束（比如
sc.sid里存在stu中没有的值），得先清理或修正数据
级联删除的隐性风险点
它跑得太快，快到你来不及后悔。一条 DELETE FROM stu WHERE sid = 102 可能顺手干掉几十条甚至上千条子记录，而 MySQL 不会提示“将影响 N 行”。
- 事务中执行更安全：
BEGIN; DELETE FROM stu WHERE sid = 102; -- 检查结果后再 COMMIT 或 ROLLBACK -
SET FOREIGN_KEY_CHECKS = 0临时关闭外键检查只适用于迁移或修复场景，绝不能用于日常删除逻辑 - 线上环境建议禁用
ON UPDATE CASCADE，主键变更本就不该发生；若真需改标识，应走应用层重映射 + 历史数据归档
真正麻烦的不是配置不会写，而是没意识到级联一旦生效，就没有“撤销”这回事。
