正确关闭外键检查需手动执行SET FOREIGN_KEY_CHECKS = 0;并在同一连接中紧邻ALTER TABLE操作，完成后立即执行SET FOREIGN_KEY_CHECKS = 1;，图形界面操作因新建连接导致失效。
MySQL Workbench 里关外键检查的正确姿势
直接在图形界面里点「query」→「set foreign key checks to off」是无效操作，它只影响当前会话的 sql 执行环境，但很多结构修改（比如删列、改类型）会触发隐式 ddl 重写，此时外键检查仍会生效并报错。
真正起作用的方式是手动执行语句，并确保它在目标操作前立即生效：
-
SET FOREIGN_KEY_CHECKS = 0;必须在同一个连接、同一事务（或非事务上下文）中执行，且紧挨着你要做的ALTER TABLE - 执行完结构变更后，务必补上
SET FOREIGN_KEY_CHECKS = 1;，否则后续插入/更新可能破坏数据一致性 - Workbench 的「Alter Table」可视化编辑器默认不自动加这句，得自己切到 SQL 模式手写
phpMyAdmin 中清空外键检查却仍报错？检查执行范围
phpMyAdmin 的「SQL」标签页里执行 SET FOREIGN_KEY_CHECKS = 0; 后，如果接着点「Structure」→「Change」去改字段，依然报 Cannot delete or update a parent row，是因为：这个图形操作新开了一条连接，之前的 SET 不生效。
解决办法只有两个：
- 全程用 SQL 标签页操作：把
SET FOREIGN_KEY_CHECKS = 0;、ALTER TABLE ...、SET FOREIGN_KEY_CHECKS = 1;写在同一段 SQL 里，用「Go」执行 - 或者在「Settings」→「SQL Queries」里勾选「Enable foreign key checks by default」改为关闭——但这会影响所有后续操作，风险更高
Django Admin 或迁移脚本里绕过外键检查的陷阱
用 python manage.py dbshell 进去手动关检查，对 Django 自动迁移没用。Django 的 migrate 命令会新建连接，且默认不透传会话变量。
安全做法是：
- 在自定义迁移文件的
RunPython或sqlmigrate输出后手动编辑 SQL，加入SET FOREIGN_KEY_CHECKS = 0;开头 - 用原生 SQL 迁移时，确认数据库用户有
SET权限（部分托管 MySQL 如阿里云 RDS 默认禁用） - PostgreSQL 用户注意：
SET CONSTRAINTS ALL DEFERRED是等效方案，但语法和行为完全不同，不能照搬 MySQL 写法
关了外键检查之后，哪些操作其实仍然会失败
以为关掉 FOREIGN_KEY_CHECKS 就能为所欲为？不是。它只跳过外键约束校验，不影响其他限制：
-
ALTER TABLE ... DROP COLUMN如果该列是联合主键一部分，会报Incorrect table definition，和外键无关 - 修改字段类型时若存在隐式转换失败（比如 TEXT → INT），照样中断，错误信息是
Data truncated for column - InnoDB 表空间不足、内存临时表超限等底层问题，不会因关外键而消失
最常被忽略的一点：关检查只对当前连接有效，如果应用用了连接池（如 SQLAlchemy + pgbouncer / mysql-connector pool），你手工执行的 SET 对业务请求完全无影响。
