最稳妥做法是先查清外键名及ON DELETE行为，再按场景选择CASCADE、SET NULL或解除约束等路径；直接SET FOREIGN_KEY_CHECKS=0属应急绕过，易致数据不一致。
直接删会报错，因为外键约束阻止删除被子表引用的父表记录；最稳妥的做法不是硬关检查，而是先看清约束行为、再选对路径。
查清外键名和当前ON DELETE行为
不先知道外键叫什么、它怎么定义的，后面所有操作都可能出错。错误常表现为 Cannot delete or update a parent row: a foreign key constraint fails，但真正卡点在约束本身。
- 用
SHOW CREATE TABLE 表名;查建表语句，定位类似CONSTRAINT `fk_order_user_id` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE的行 - 重点看
ON DELETE后面的关键词：CASCADE、RESTRICT、SET NULL或没写（等同于RESTRICT） - 如果没显式定义，MySQL 默认是
RESTRICT，也就是禁止删除——这是你报错的根源
按场景选删除方式：别一上来就SET FOREIGN_KEY_CHECKS=0
临时关检查不是“解法”，而是绕过校验的应急手段，容易埋雷。不同场景该走哪条路：
- 日常业务中父子必须共存亡（比如
orders和order_items），应该在建表时就用ON DELETE CASCADE，后续删父记录自动清理子记录 - 只想删某几条父记录，且子记录仍有业务意义（比如停用某个服务但保留历史订单），改用
ON DELETE SET NULL，前提是子表外键字段允许为NULL - 仅测试环境批量清空、或需严格控制顺序（如先删
logs再删users），才用SET FOREIGN_KEY_CHECKS=0；但必须配对执行SET FOREIGN_KEY_CHECKS=1，否则下一条INSERT可能静默失败
想删整张父表？先解约束再DROP，别TRUNCATE
TRUNCATE 在有外键引用时必然失败，哪怕关了 FOREIGN_KEY_CHECKS 也不行（InnoDB 层限制）。真要删表，得走标准流程：
- 先查出子表上的外键名：
SHOW CREATE TABLE 子表名; - 在子表上删外键：
ALTER TABLE 子表名 DROP FOREIGN KEY `外键名`;（注意反引号） - 再删父表：
DROP TABLE 父表名; - 如果之后还要重建，记得补回外键约束，否则数据一致性就断了
最容易被忽略的是：外键约束名不是列名，也不是表名，必须从 SHOW CREATE TABLE 里原样抄；漏掉反引号、拼错名字、或者误删了索引却没清理冗余 INDEX，都会让后续操作卡住。
