先查清所有依赖关系，再决定是否操作外键；运行SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'user' AND REFERENCED_COLUMN_NAME = 'id'可完整列出引用user.id的子表，注意MySQL 8.0+权限限制。
直接删表或执行导入失败，不是SQL写错了，是MySQL在拦你——有其他表正通过外键指着这张表。迁移卡在外键上，核心就一条：先看清谁在依赖谁，再决定动不动约束。
怎么快速查清所有引用 user 表 id 字段的子表？
错误信息里只说 CONSTRAINT `push` FOREIGN KEY (`pushid`) REFERENCES `user` (`id`)，但不会告诉你还有没有别的表也引用 user.id。得自己查全：
- 运行
SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'user' AND REFERENCED_COLUMN_NAME = 'id' - 注意权限问题：MySQL 8.0+ 的
INFORMATION_SCHEMA默认只返回当前用户有权限的表，权限不足会漏结果 - 如果目标库是空的但导入报错，重点检查导出 SQL 中
CREATE TABLE语句里的FOREIGN KEY定义，尤其是ON DELETE和ON UPDATE是否写了、写得对不对
SET FOREIGN_KEY_CHECKS = 0 能不能用？怎么用才安全？
能用，但必须严格配对、限定范围、避开生产陷阱：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 只在单个 SQL 文件头部加
SET FOREIGN_KEY_CHECKS = 0;，结尾加SET FOREIGN_KEY_CHECKS = 1;，别指望客户端自动恢复 - 禁用期间绝对不能执行任何业务写入，否则可能写入非法外键值（比如
user_id = 999但users表没这条） -
mysqldump默认带--skip-foreign-key-checks，但它只影响导入行为，不影响你手动执行的 SQL - 千万别在连接池复用的生产环境会话里设
FOREIGN_KEY_CHECKS = 0——这个变量是会话级的，连接可能被其他请求复用
迁移时要不要临时加 ON DELETE CASCADE？
不建议。这不是懒，是怕状态不可逆：
-
ALTER TABLE DROP FOREIGN KEY需要知道约束名，而不同环境导出的约束名可能不一致（比如fk_orders_user_idvsorders_ibfk_1），脚本容易断 - 已有数据的表加
ON DELETE CASCADE，会触发全量级联删除动作，迁移过程万一中断，状态难回滚 - 如果下游依赖触发器清理缓存，
CASCADE会绕过这些逻辑，导致缓存与数据库不一致 - 真正稳妥的做法是把“删表”变成“清空+重建”，把“更新”变成“插入新记录+删旧记录”，从源头避开外键拦截点
外键约束本身不是敌人，但迁移时它最讨厌模糊操作——查依赖要全，关检查要准，改结构要慎。最容易被忽略的是权限和会话隔离这两个点，一漏就进坑。
