为何Django Migrate添加null=True时会重建外键约束？

首先可以明确告诉你：这在Django 2.0.5 + PostgreSQL 9.6.9的环境下是完全正常的行为，不用过度恐慌，但我们得搞清楚背后的原因，以及生产环境执行时的注意事项。

先回顾一下你的变更和迁移输出：

你的Model变更 #

- live = models.ForeignKey('live.Live', on_delete=models.CASCADE, related_name='live_likes')
+ live = models.ForeignKey('live.Live', on_delete=models.SET_NULL, related_name='live_likes', null=True)

你提到“仅有的差异是添加了null=True”，但其实还有一个关键变更：on_delete从CASCADE改成了SET_NULL——这才是触发约束重建的核心原因之一。

Django生成的迁移SQL #

SET CONSTRAINTS "live_like_live_id_0374bfe6_fk_live_live_id" IMMEDIATE;
ALTER TABLE "live_like" DROP CONSTRAINT "live_like_live_id_0374bfe6_fk_live_live_id";
ALTER TABLE "live_like" ALTER COLUMN "live_id" DROP NOT NULL;
ALTER TABLE "live_like" ADD CONSTRAINT "live_like_live_id_0374bfe6_fk_live_live_id" FOREIGN KEY ("live_id") REFERENCES "live_live" ("id") DEFERRABLE INITIALLY DEFERRED;

为什么会出现约束重建？ #

主要有两个原因：

1. PostgreSQL不支持直接修改外键的ON DELETE行为
   外键约束的ON DELETE（比如CASCADE/SET_NULL）是约束定义的一部分，PostgreSQL没有提供直接修改现有约束该属性的语法。要变更这个行为，必须先删除旧约束，再创建带有新行为的新约束。

2. null=True需要修改列的非空属性，与外键约束的联动
   当你把外键列从非空改为允许空值时，Django的迁移系统会认为需要配合外键约束的重建来完成这个变更——虽然理论上修改列的NOT NULL属性和外键约束是独立操作，但Django 2.x版本的迁移生成逻辑会将这两个操作绑定在一起执行。

生产环境执行的风险和注意事项 #

虽然这个操作是正常的，但在生产环境中还是需要留意：

• 锁表问题：删除和重建外键约束会对live_like表加锁，在高并发场景下可能会短暂阻塞读写。建议选择业务低峰期执行迁移。
• 事务安全性：PostgreSQL的Django迁移是在事务中执行的，如果任何一步出错，整个迁移会回滚，不会让你的表处于损坏状态。
• 数据检查：执行迁移前，确保live_like表中没有依赖于被删除Live实例的记录（不过你已经改成SET_NULL，所以如果有这类记录，迁移后live_id会被设为NULL，这是符合预期的）。

总之，这个行为是Django针对PostgreSQL特性的正常处理逻辑，只要做好生产环境的执行规划，不会导致严重故障。

内容的提问来源于stack exchange，提问作者SangminKim