查外键应联合TABLE_CONSTRAINTS和KEY_COLUMN_USAGE两表关联查询，生成DROP语句需显式拼接TABLE_SCHEMA、加反引号防语法错误，执行前设FOREIGN_KEY_CHECKS=0并验证残留。
查外键不能只看 KEY_COLUMN_USAGE
很多人直接查 information_schema.KEY_COLUMN_USAGE，以为 REFERENCED_TABLE_NAME IS NOT NULL 就能捞全所有外键，但漏掉了两种情况：一是复合外键中某列被引用但整条约束没出现在该视图里；二是 MySQL 8.0+ 对部分系统表权限做了收紧，默认用户可能查不到完整信息。更稳的方式是联合 TABLE_CONSTRAINTS 和 KEY_COLUMN_USAGE 两表，用 CONSTRAINT_NAME 做关联。
生成 DROP FOREIGN KEY 语句时注意表名和库名拼接
直接拼 TABLE_NAME 容易出错，尤其当表在非默认 schema 时。必须显式带上 TABLE_SCHEMA，否则执行会报 Unknown table 或误删其他库同名表。
- 正确写法：
CONCAT('ALTER TABLE `', c.TABLE_SCHEMA, '`.`', c.TABLE_NAME, '` DROP FOREIGN KEY `', c.CONSTRAINT_NAME, '`;') - 别漏反引号：表名或约束名含下划线、数字开头、或为保留字（如
order）时，不加反引号会语法错误 - 避免用
GROUP_CONCAT一次性拼太长：默认长度限制是 1024 字符，外键多时会被截断，应先设SET SESSION group_concat_max_len = 1000000;
执行前必须关掉外键检查再跑生成的语句
哪怕你生成的是标准 DROP FOREIGN KEY 语句，执行时仍可能因隐式依赖失败——比如某个外键正被触发器引用，或约束名在当前 session 缓存里已失效。最保险的做法是把整个操作包进一个 session 控制流：
- 先执行
SET FOREIGN_KEY_CHECKS = 0; - 再执行你拼出来的所有
ALTER TABLE ... DROP FOREIGN KEY语句 - 最后执行
SET FOREIGN_KEY_CHECKS = 1; - 不要依赖脚本自动恢复：万一中间报错退出，
FOREIGN_KEY_CHECKS会一直关着，后续写入可能破坏数据一致性
删完立刻验证是否真没了
光看“Query OK”不等于外键消失。有些约束名带特殊字符或空格，拼接时被截断，导致部分语句实际没执行成功。验证必须手动查：
- 查残留：
SELECT COUNT(*) FROM information_schema.TABLE_CONSTRAINTS WHERE CONSTRAINT_TYPE = 'FOREIGN KEY' AND CONSTRAINT_SCHEMA = 'your_db_name';返回 0 才算清干净 - 别信
SHOW CREATE TABLE输出里的 KEY 行：它只显示索引，不反映外键是否存在；得看输出里有没有CONSTRAINT `xxx` FOREIGN KEY这样的行 - 如果用 Liquibase 或 Flyway 管理变更，删完外键后记得同步更新 changelog，否则下次部署会因约束缺失报错
information_schema 的字段兼容性差异——比如 5.7 里 REFERENCED_TABLE_SCHEMA 可能为空，而 8.0 要求它非空才能认定是外键。动手前先确认你连的是哪个版本。 
