禁用外键约束检查（set foreign_key_checks=0）是临时跳过校验，保留外键结构；而alter table drop foreign key会永久删除外键定义及关联索引，丢失约束逻辑与级联行为，不可逆且需重写完整语法。
禁用外键约束检查不是删除外键，而是临时绕过约束校验——必须用 SET foreign_key_checks = 0;，且仅对当前会话生效。
为什么不能用 ALTER TABLE DROP FOREIGN KEY 代替？
因为 DROP FOREIGN KEY 是永久移除外键定义，会丢失约束逻辑和索引（如果该索引是外键自动创建的），后续再加回来要重写完整语法、确认列类型匹配、ON DELETE/UPDATE 行为等。而禁用检查只是跳过校验，外键结构原封不动保留，适合导入数据、批量删改、表结构调整等临时场景。
常见错误现象：ERROR 1217 (HY000): Cannot delete or update a parent row: a foreign key constraint fails 或导入 SQL 时卡在某条 INSERT 报错。
- 只影响当前连接（session），其他客户端不受影响
- 不会自动恢复，必须显式执行
SET foreign_key_checks = 1; - 若会话异常断开，变量会重置为 1，但脚本中没写开启语句就容易遗漏
执行顺序和典型操作链
禁用不是孤立动作，它必须嵌入明确的操作流程中，否则极易导致数据不一致。
典型安全链路如下：
- 先查当前状态：
SELECT @@foreign_key_checks;（确认是否已为 0） - 禁用：
SET foreign_key_checks = 0; - 执行目标操作（如
TRUNCATE TABLE parent;、INSERT ... SELECT、ALTER TABLE ... DROP COLUMN） - 立即启用：
SET foreign_key_checks = 1; - 可选验证：
SELECT * FROM child WHERE parent_id NOT IN (SELECT id FROM parent);找出可能残留的孤儿记录
哪些操作必须配合 foreign_key_checks=0？
不是所有 DML 都需要关外键检查，只有涉及「违反参照完整性但你明知可控」的场景才适用。
常见必须关闭的场景：
- 清空主表前不先删子表（
TRUNCATE TABLE parent直接报错） - 从旧库导入数据到新库，而新库外键已建好，但导入顺序无法保证父表先于子表
- 批量更新主表主键值（比如迁移 ID 规则），又不想逐条级联更新子表
- 执行
mysqldump --no-create-info导出的数据重载，因无建表语句，外键约束已存在但数据顺序混乱
注意：DELETE FROM parent 和 UPDATE parent SET id=... 即使开了检查也可能成功——取决于 ON DELETE/UPDATE 定义，不一定需要关检查。
容易被忽略的兼容性与陷阱
foreign_key_checks 是会话级变量，但它的行为在不同 MySQL 版本和存储引擎下有细微差别。
- 仅对 InnoDB 表生效；MyISAM 表无视该设置（本身不支持外键）
- MySQL 5.7+ 中，
SET foreign_key_checks = 0不影响CREATE TABLE ... FOREIGN KEY语句的解析，但建表后插入数据仍受约束（除非再关一次） - 使用
mysqldump --skip-foreign-key-checks时，导出的 SQL 文件里默认包含SET FOREIGN_KEY_CHECKS=0;开头和结尾，但如果你手动拼接或分段执行，这个包裹容易被删掉 - 在存储过程中不能动态修改该变量（会报错
ERROR 1238 (HY000): Variable 'foreign_key_checks' is a READ ONLY variable）
最常被跳过的一步：执行完操作后忘记 SET foreign_key_checks = 1;，导致后续所有 INSERT/UPDATE 都静默跳过校验，几小时后才发现子表里塞了一堆无效 parent_id。
