Django怎么进行数据库迁移_Python使用makemigrations与migrate指令

Django数据库迁移：从“玄学”到可控的实战指南

话说回来，Django的数据库迁移系统堪称“开发者的福音，运维的噩梦”。它自动化了数据库变更，但偶尔也会制造一些令人挠头的“惊喜”。今天，我们就来聊聊几个最常见的迁移陷阱及其破解之道，帮你把迁移从“玄学”变成可控的工程实践。

makemigrations 什么情况下会生成空迁移文件

你有没有遇到过这种情况？明明改了模型，信心满满地执行 python manage.py makemigrations，终端却冷冰冰地回你一句“No changes detected”。这通常意味着Django的变更探测器“失灵”了，背后原因往往很微妙。

• 交互式默认值的“坑”：给已有字段添加 default 但没设 null=True 时，Django会停下来，要求你为现有记录输入一个临时默认值。这时候如果你直接敲了回车，或者跳过了交互，就可能生成一个看似正常、实则逻辑有缺陷的迁移文件，甚至直接“空跑”。

• “改名”引发的误会：字段名拼写错误，或者只改了 db_column 而没动字段名，Django很可能不认为这是重命名。它会误判为“新增一个字段，同时旧字段被废弃”，从而生成“删除旧字段”和“添加新字段”两步操作，而不是你期望的 RenameField。

• 非空约束的“历史难题”：在已有数据的表上，给字段加上 blank=False 或 null=False 约束，却不提供 default 值，这等于给Django出了道难题：历史数据该填什么？此时它会让你做出选择：要么提供一个一次性填充值，要么中止迁移。选错选项，生成的迁移逻辑就可能与预期不符。

migrate 执行时报错 “Table already exists” 或 “column does not exist”

看到这类错误先别慌，数据库本身可能没问题，问题大概率出在Django的“账本”—— django_migrations 表——和实际数据库结构对不上号了。

• 手动操作的“后遗症”：如果曾经手动在数据库里删除过某张表，却没有同步清理 django_migrations 表中对应的记录，那么下次执行 migrate 时，Django会以为这张表还没创建，于是再次尝试建表，自然就撞上了“Table already exists”的错误。

• 迁移文件被“污染”：直接编辑迁移文件内容（比如把操作类型从修改字段改为重命名字段）是高风险行为。如果忘了同步更新该文件头部 dependencies 所声明的依赖关系，就可能打乱迁移的执行顺序，导致Django在错误的时间点操作一个尚不存在的字段，从而报出“column does not exist”。

• 团队协作的“编号冲突”：这是经典场景。同事A已经提交了 0002_add_xxx.py 迁移文件，而你的本地代码库还停留在 0001_initial.py。此时你若运行 makemigrations，Django也会生成一个名为 0002_… 的文件，但内容可能与A的完全不同。这种冲突若不妥善解决（如重命名、调整依赖），后续的 migrate 要么静默跳过关键步骤，要么直接报错。

如何安全地回退一次迁移

回滚迁移是必备的逃生技能。命令很简单：python manage.py migrate myapp 0002。这里的“0002”是目标迁移的名称（不含.py后缀），意思是让应用回退到0002这个版本的状态。

但有几个关键细节必须注意：

• 回退的本质：这个操作并不会删除磁盘上的迁移文件，它主要做两件事：一是从 django_migrations 表中移除后续版本的记录；二是按相反顺序执行当前版本之后所有迁移文件中 operations 的逆向操作（比如添加字段的逆向操作就是删除字段）。

• 自定义代码的回滚：如果迁移中包含 RunPython 操作，并且你没有为其编写 reverse_code（反向代码），那么回退到该迁移之前版本的操作将会失败。这意味着，对于数据迁移，正向和反向的逻辑都需要明确定义。

• 版本管理的红线：已经提交到版本控制系统（如Git）的迁移文件，绝对不要手动删除。因为其他开发者在拉取代码后，他们的迁移依赖链可能会因此断裂，导致 migrate 无法进行。

生产环境千万别直接跑 makemigrations

这是用血泪教训换来的铁律：线上数据库的变更，必须由经过人工审核的、确定的迁移文件来驱动，绝不能依赖在服务器上自动运行 makemigrations。

• 预览不等于保险：虽然 makemigrations --dry-run 可以预览将要生成的操作，但它并非百分百可靠。尤其是在进行数据敏感型变更时，比如将 TextField 改为长度有限的 CharField，或者为已有字段添加唯一约束（UNIQUE），Django的探测器不会去检查现有数据是否违反这些新约束，直接应用可能导致运行时错误。

• 标准的线上流程：正确的做法应该是：在本地开发环境修改模型 -> 运行 makemigrations 生成迁移文件 -> 人工打开这个迁移文件，仔细审查 operations 列表是否符合预期 -> 必要时手动编辑迁移文件，使其更安全（例如，添加一个不可空字段，可以拆解为：先添加可为空的字段，然后用 RunPython 填充所有现有记录的值，最后再将字段改为不可空）-> 将审核无误的迁移文件提交到代码库 -> 在线上环境，只执行 migrate 命令。

• 最隐蔽的依赖陷阱：迁移文件头部的 dependencies 是硬编码的依赖关系。在团队协作中，如果合并代码时处理不当，导致依赖关系出现循环或缺失，migrate 可能会静默地跳过某些关键迁移步骤，从而埋下数据结构不一致的隐患。定期检查迁移依赖图的健康状态，是个好习惯。

立即学习“Python免费学习笔记（深入）”；