MySQL不支持直接修改外键的ON DELETE行为，必须先DROP再ADD；需准确获取并指定外键名，重建时须完整定义约束；CASCADE有数据丢失和性能风险，建议建表时规范命名与显式声明级联规则。
直接修改外键的 ON DELETE 行为不可行
MySQL 不允许用 ALTER TABLE ... MODIFY FOREIGN KEY 或类似语法直接修改已有外键的 ON DELETE 或 ON UPDATE 规则。你执行类似操作时会报错：ERROR 1025 (HY000): Error on rename of './db/#sql-...' to './db/table_name' (errno: 152) 或提示“cannot change column type incompatible with foreign key”。这不是权限或语法写错，而是 InnoDB 引擎本身的限制。
必须先删后加：两步完成级联规则变更
正确做法是显式删除旧外键，再以新规则重建。关键点在于：外键名必须准确，否则 DROP FOREIGN KEY 会失败。
- 先查出当前外键名：
SHOW CREATE TABLE child_table;—— 在输出中找类似CONSTRAINT `fk_emp_dept_id` FOREIGN KEY (`dept_id`) REFERENCES `dept` (`id`) ON DELETE RESTRICT的行，提取约束名（如fk_emp_dept_id） - 删掉它：
ALTER TABLE child_table DROP FOREIGN KEY fk_emp_dept_id; - 重建带新规则的外键：
ALTER TABLE child_table ADD CONSTRAINT fk_emp_dept_id FOREIGN KEY (dept_id) REFERENCES dept(id) ON DELETE CASCADE;
注意：ADD CONSTRAINT 必须指定完整定义（包括列名、引用表、引用字段），不能只写规则部分；如果原外键没命名，InnoDB 自动生成的名通常形如 child_table_ibfk_1，需从 SHOW CREATE TABLE 中确认。
ON DELETE CASCADE 的实际影响与风险
启用后，删除父表某行会自动连带删除子表所有匹配外键的行，不触发子表的 BEFORE DELETE 触发器，也不走应用层逻辑。这省事但危险：
- 没有事务回滚提示——一旦误删父记录，子数据瞬间消失，且不会进 binlog 的 row 格式“delete_rows”事件（除非开启 full logging）
- 若子表数据量大（比如百万级日志表），
CASCADE可能锁表时间长，引发主从延迟或连接堆积 -
SET NULL要求子表外键列允许NULL，否则建约束失败；RESTRICT和NO ACTION效果相同，都是阻止父表删改
开发阶段建议：外键名统一 + 级联规则显式声明
避免后期维护踩坑，建表时就该规范处理：
- 始终给外键命名（如
fk_order_user_id），别依赖自动生成名 - 级联行为写全：
ON DELETE CASCADE ON UPDATE CASCADE或按需选SET NULL - 在迁移脚本或 ORM 模型中同步记录外键策略，而不是靠 DBA 临时查
SHOW CREATE TABLE
真正麻烦的不是改一次规则，而是多人协作时有人绕过 DDL 直接改表结构，导致外键名失效或级联逻辑不一致——这种隐性差异在线上查问题时最难定位。
