mysql外键需先查名再删建，字段定义须完全一致，set foreign_key_checks=0对ddl无效，on update cascade需压测防性能风险。
ALTER TABLE DROP FOREIGN KEY 后必须先查出原外键名
MySQL 不允许直接修改外键行为，只能先删后建。但 DROP FOREIGN KEY 语法要求你提供外键名称，而这个名称不是你创建时写的 fk_name（如果没显式指定），而是 MySQL 自动生成的。常见错误是直接写 ALTER TABLE t DROP FOREIGN KEY fk_dept_id 却报错 Can't find index for foreign key。
正确做法是先查：
SHOW CREATE TABLE child_table;
在输出中找类似 CONSTRAINT `fk_123456789` FOREIGN KEY (`dept_id`) REFERENCES `dept` (`id`) ON DELETE RESTRICT 这样的行，把反引号里的名字（如 fk_123456789）复制下来备用。
重建外键时 ON DELETE CASCADE 必须和原约束字段完全匹配
重建外键不只是加个 ON DELETE CASCADE 就完事。字段类型、长度、是否允许 NULL、字符集、排序规则，都必须和原外键列及父表被引用列严格一致。哪怕只是 VARCHAR(20) 和 VARCHAR(25) 差 5 个字符，ADD CONSTRAINT 就会失败并报 ERROR 1005 (HY000): Can't create table。
实操建议：
- 用
DESCRIBE parent_table;和DESCRIBE child_table;对比字段定义 - 确保子表外键列已有索引（InnoDB 要求外键列必须有索引）
- 语句中显式写出所有约束细节，例如：
ALTER TABLE child_table ADD CONSTRAINT fk_child_parent FOREIGN KEY (parent_id) REFERENCES parent_table(id) ON DELETE CASCADE ON UPDATE RESTRICT;
SET FOREIGN_KEY_CHECKS = 0 只对 INSERT/UPDATE/DELETE 生效，不影响 DDL
有人误以为关掉外键检查就能跳过约束验证来重建外键，其实没用。SET FOREIGN_KEY_CHECKS = 0 只禁用运行时的参照完整性检查，对 ALTER TABLE 这类 DDL 操作无效。重建外键时若数据已违反新约束（比如子表里有 parent_id = 999，但父表没有这条记录），ADD CONSTRAINT 仍会失败。
所以必须保证当前数据合法：
- 先清理脏数据：
DELETE FROM child_table WHERE parent_id NOT IN (SELECT id FROM parent_table); - 或补全缺失父记录（谨慎操作）
- 再执行外键重建
ON UPDATE CASCADE 在生产环境要压测，别只看语法对不对
虽然 ON UPDATE CASCADE 语法上支持，但批量更新父表主键（比如 UPDATE parent_table SET id = id + 100000）会触发子表逐行更新。一次改 1 万条父记录，若平均每个父记录关联 5 条子记录，就等于执行 5 万次子表 UPDATE，还可能锁表、拖垮索引性能。
更稳的做法是：
- 业务层控制：避免更新主键值，用逻辑 ID（如
code字段）替代物理主键做业务关联 - 真要改，用“复制+切换”：新建临时表，导入新主键数据，原子替换原表
- 若坚持用
ON UPDATE CASCADE，上线前务必在影子库压测相同数据量级的更新
外键行为一旦生效，就不是改一条 SQL 能撤回的；最麻烦的不是加约束，而是发现它在高并发下成了性能瓶颈时，再想拆又得面对数据一致性风险。
