mysql外键的介绍

这是一个陷阱。
外键会增加维护成本并影响写入性能。
使用高并发或大数据量时应谨慎。

如何在MySQL中清理错误的约束条件？通过ALTER TABLE DROP CONSTRAINT修复

说实话，当谈到 MySQL 的局限性时，我经历过很多陷阱。
你说的流程很清楚，但是在实际工作中需要注意一些细节。
让我给你补充一些我自己的经验。

我们先来说一下定位约束的名称。
使用SHOW CREATE TABLE确实是最直观的，特别适合初学者。
我有一个客户，一家电子商务公司。
表结构非常复杂，由数百张表组成。
他第一次使用这个命令时，对结果感到困惑。
结果，它跳过了 CONSTRAINT，几乎删除了不应该删除的约束。
所以最好配合grep或者IDE的搜索功能使用，效率很高。

INFORMATION_SCHEMA.TABLE_CONSTRAINTS 这种方式比较先进，适合自动化运维。
我以前在编写使用公司遗留数据库的脚本时使用过它。
当时有一张桌子，有很多限制。
我直接使用SQL查询创建Excel表格，然后批量修改。
然而，有一个小问题。
MySQL 5 .7 和8 .0输出格式略有不同，所以要注意版本兼容性。

在解除限制之前备份数据是老生常谈的事，但在操作时很容易忘记。
我有一个同事在删除外键之前没有检查相关表数据。
结果，所有的数据都混淆了。
他半夜把它捡起来，花了很长时间才完成。
所以工作之前需要在测试环境中运行一下，尤其是外键约束。
我建议使用 pt-online-schema-change 工具。
该工具会在删除外键时暂停相关表，以免影响线上业务。

删除主键约束是一个雷区。
我记得有一次删除了表的主键。
由于MySQL默认使用主键创建聚集索引，导致整个表中数据的顺序乱序。
后来又花了半天时间进行调整数据存储顺序。
因此，在删除主键之前，最好检查下表是否使用了聚集索引。
否则影响不大。

检查约束（CHECK）其实用处不大，但在MySQL 8 .0之后终于支持了。
有朋友在使用分区表时特别需要CHECK约束。
但需要注意的是，删除 CHECK 约束的语法与其他约束的语法相同，但如果没有检查逻辑，数据插入可能会被破坏。

最后，有一个小问题：删除唯一约束会同时删除唯一索引，但使用 DROP INDEX 命令直接删除索引，限制仍然存在。
我在优化表结构的时候就遇到了这种情况。
我以为这个限制被错误地取消了，但是通过阅读手册才发现。
这点应特别注意。

简而言之，在解决约束问题时，谨慎胜过技术。
我建议您在开始之前备份与约束关联的所有表，以便在出现问题时可以回滚。
测试环境必须模拟整个业务流程，尤其是外键关系表，不能只测试删除操作本身。