MySQL外码如何设置_MySQL外键约束创建与关联表设计教程

记得上次在咖啡馆帮同事调试数据库时，他因为一个订单表突然出现了无效的客户ID，急得满头大汗。
我一看，原来是新员工上线的时候忘记给外键添加约束了。
这东西让我想起了外键，真是隐形的保镖。

创建外键其实非常简单。
比如写代码的时候，我习惯先画草图。
有一个电子商务系统。
我画了一张客户表和一张订单表。
客户表有一个自增ID，订单表有一个客户ID。
这时候就不仅仅是添加一个INT列了，还要添加：
sql 创建表客户（ id INT 自动递增主键， 名称 VARCHAR(1 00) );
创建表订单 ( order_id INT 自动递增主键， customer_id INT NOT NULL, 订单日期DATETIME， 约束 fk_customer 外键 (customer_id) 参考客户 (id) 关于删除限制 关于级联更新 );
关键点是ON DELETE RESTRICT，就像现实中的门禁系统一样。
你不能让客户突然消失但订单还在，对吧？ ON UPDATE CASCADE 甚至更好。
例如，如果客户搬家，所有订单地址都会自动更新，而无需手动更改每个项目。

但是修改现有的表并添加外键会很麻烦。
当我接手一个项目时，发现表已经建好很久了，数据量巨大。
这时候就得先检查：
sql SELECT o.order_id, c.name FROM 订单 o LEFT JOIN 客户 c ON o.customer_id = c.id 其中 c.id 为 NULL；
突然我想到一件事。
虽然外键约束很好，但确实减慢了速度。
在测试环境插入数据时，我开启了外键检查，每秒只添加了5 0条。
关掉之后，这个数字猛增到了2 000。
这就是为什么一些大厂商在开发业务库时不使用外键，而是在应用层做验证。

现在很多 IDE 都有外键提示。
比如Navicat，一键就能看到约束关系。
但不一致的字符集存在一个缺陷。
我见过有人写一个 VARCHAR(2 0) 外键，但另一边是 VARCHAR(3 0)。
虽然可以保存数据，但是根本不认识约束。
这就像一个真正的邮箱。
如果您将大信封放入小邮箱，邮局将不会接受。

最近在研究MySQL 8 .0的延迟外键，觉得这个技术蛮有趣的。
即可以先插入子表，后检查外键约束。
如果您有物流系统，它会派上用场。
例如，您可以在包裹进入仓库时对其进行记录，然后扫描到终点后确认客户ID。
但实施起来很复杂。
您必须编写自己的触发器并维护临时表。

改表、添加外键时，最怕的是锁表。
有一次凌晨3 点执行了ALTER TABLE，但运维发现整栋楼都无法连接。
后来，我改用ALGORITHM=INPLACE。
虽然数据还是全红，但至少没有影响白天的生意。
这就像修一条路。
全封闭施工不如夜间单车道分时施工。

现在想一想，外键约束是不是像父母控制孩子一样？ RESTRIC表示严格纪律，CASCADE表示言传身教，SET NULL表示放手。
但最好的事情可能是不采取行动，既不强制也不反对，并允许孩子们做出自己的选择。
就像现在很多00后一样，你说他们不听，他们其实知道自己想要什么。

等一下，还有一件事。
级联外键更新存在隐藏风险。
我已经看到使用 ON UPDATE CASCADE 会导致连锁反应。
当客户的电话号码发生变化时，关联的订单状态也会发生变化。
这就像现实中谣言的传播一样。
一个笑话可以成为大新闻。

现在外键约束是由IDE自动生成的，但是出现问题时没有人会关心。
我记得有一个团队删除了开发环境中的所有约束。
结果到生产时，他们发现客户表和订单表有1 00万条不匹配的数据。
这就像考试作弊的习惯，真正想参加正式考试的时候却连笔都拿不稳。

MySQL如何改主键_MySQL主键修改与约束调整教程

嘿，升级 MySQL 主键的过程是一项相当技术性的任务。
你必须小心，不能粗心。
说实话，我从事这个行业很多年了，遇到过很多这样的情况，而且每次都得一步步去做。
1 、主要步骤如下：
1 ．检查和管理外键依赖关系：首先需要查看哪些外键依赖于这个主键，并一一处理。
您无法全局禁用它们，这会产生一个大问题。
记得有一次，表的外键是基于几个相关的表，必须一一禁用。
2 .删除旧的主密钥：这一步要小心，特别是如果旧的主密钥具有自动增量功能，则必须先将其删除。
例如，您应该这样做：ALTERTABLE your_tableMODIFYidINTNOTNULL;然后执行 ALTERTABLEyour_tableDROPPRIMARYKEY;
3 .修改新主键列属性：新主键必须非空且唯一，并且必须保证数据类型正确。
有时你需要改变。
4 . 添加新的主键：这一步很简单。
直接添加新的主键。
如果自动递增，则添加 AUTO_INCRMENT。
5 . 恢复外键约束：必须重新添加外键并启用检查，如下所示： ALTERTABLEchild_tableADDCONSTRAINTfk_nameFOREIGNKEY(child_column)ref(your_table(new_id));SETFOREIGN_KEY_CHECKS=1 有一些特别需要注意的地方。
致：
1 自动增量主键 (AUTO_INCRMENT) 处理：在更改 AUTO_INCREMENT 属性之前，必须先删除它。
不用担心兼容性问题。
2 .大表优化策略：例如可以采用OnlineDDL来减少表锁定时间。
或者使用pt-online-schema-change等第三方工具来同步数据并实现零停机。
3 、数据安全与恢复：数据库运行前应进行备份，测试环境应模拟该过程，并制定恢复计划。
3 . 风险规避和最佳实践：
1 避免并发条目：更改自动递增主键时，最好排除表中的并发条目。
2 、依赖关系设置：外键引用的自增主键和外​​键约束方式相同它们必须更新。
3 .架构优化：数据量会不断增长，可以考虑共享或者迁移到分布式数据库。

一般来说，这个问题应该尽快、一步一​​步地完成，以确保数据完整性和服务交付，而不是慢慢来。
当时我接手了一个项目，差点因为没有遵循流程而面临很大的问题。

mysql数据库怎么删除字段

你说的很明显了，但我还是老老实实的说一下我当年掉过的坑。

当时，我刚刚继承了一个旧项目，数据库中的表设计得很疯狂。
我有一个名为 users_info 的表和一个名为 mobile_code 的字段。
这是一个无用的验证码字段，我想将其删除。
直接复制你说的语句：
sql 更改表 users_info 删除列 mobile_code;
结果如何？外键约束请直接报错。
我查了一下，发现啊，这个字段是另一个表user_logs中的外键关联。
当时我很困惑，所以我很快检查了一下user_logs表中是否使用了这个字段，并且确实存在。
我就想着直接去掉，先把这个外键关系去掉。
我再次复制了你说的语句并添加了 DROP FOREIGN KEY:
sql。
更改表 user_logs 删除外键 fk_mobile_code;
这次就报错说找不到外键。
我拍拍自己的大腿，发现这张表被修改了好几次，外键的名字肯定不是fk_mobile_code。
我最终不得不手动检查INFORMATION_SCHEMA很长时间，发现外键名称是fk_user_mobile_code。
经过重命名和删除后，我终于摆脱了不必要的字段。

所以，兄弟，你说得对。
在删除字段之前应检查外键约束。
否则你会像我一样，花很长时间删除字段。
最好先在测试环境中尝试一下，而不是直接投入生产并盲目操作。