直接 drop table 失败时，先查 information_schema.key_column_usage 获取引用目标表的子表名及外键名；再根据场景选择删子表或删外键约束；禁用外键检查仅限离线无写入环境，且必须及时恢复。
查清哪些表在引用目标表
直接 DROP TABLE 失败时，错误信息类似 ERROR 1217 (HY000): Cannot delete or update a parent row: a foreign key constraint fails，说明有子表正通过外键依赖它。不能靠猜，得查元数据：
- 运行
SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'your_table_name'; - 结果中
TABLE_NAME列就是你要先处理的子表名，CONSTRAINT_NAME是外键名（如e_ibfk_1） - 如果子表本身也被其他表引用，需递归查——直到找到没有被引用的“叶子表”
删子表 or 删外键约束？看场景选
两种主流路径，适用条件完全不同：
- 想彻底清理整套关联结构（比如重置测试库）：优先
DROP TABLE子表，再删父表。顺序不能错，否则又报错 - 只想删父表、保留子表结构和数据：必须先解除子表上的外键，用
ALTER TABLE child_table DROP FOREIGN KEY fk_name; - MySQL 8.0+ 支持
DROP TABLE your_table CASCADE;，但实际行为因版本而异，不建议依赖——它不一定自动删子表，可能只删约束
临时禁用外键检查？仅限无业务写入的离线环境
SET FOREIGN_KEY_CHECKS = 0; 能绕过所有外键校验，但不是修复，是掩耳盗铃：
- 只允许在本地开发库、空测试库等确认无任何并发写入的场景下使用
- 执行后必须立刻补上
SET FOREIGN_KEY_CHECKS = 1;，漏掉会导致后续所有操作跳过外键检查 - 该设置只对当前会话生效，放进自动化脚本极易遗漏恢复步骤，生产环境严禁使用
- 禁用期间插入的数据若引用了已删父表的值，就会变成孤儿记录，MySQL 不会预警也不会修复
删表前务必确认表真实存在且名字准确
有时你以为是外键问题，其实是更基础的失误：
- 先跑
SHOW TABLES LIKE 'your_table_name';，确认表名拼写、大小写（Linux 下默认区分）、是否带横线或点号 - 如果表名含特殊字符，
DROP TABLE时必须用反引号包裹，例如DROP TABLE `my-table`;，否则语法解析失败 - 错误
Can’t drop table ‘x’: check that column/key exists和外键无关，99% 是表不存在或名字输错
INFORMATION_SCHEMA，比事后 debug 强十倍。
