如何在Django 3.2长周期支持版本中安全地迁移SQL数据-SQL-PHP中文网

django 3.2 数据迁移必须分离结构与数据操作，添加非空字段、重命名、拆分/合并字段、类型转换、跨模型迁移等场景需手动编写 runpython/runsql；务必用 --empty 创建迁移文件、分页处理大数据、注意数据库差异及 atomic=true 保证原子性。

如何在django 3.2长周期支持版本中安全地迁移sql数据

在 Django 3.2（LTS）中安全迁移 SQL 数据，核心是「结构迁移」和「数据迁移」必须分离处理，且不能依赖 makemigrations 自动生成数据逻辑——它只管 schema，不管数据一致性。

什么时候必须写自定义数据迁移而不是靠 `makemigrations`

Django 的 makemigrations 只检测模型定义变更，不会为你生成数据转换逻辑。以下场景必须手动写数据迁移：

添加非空字段（CharField、IntegerField 等）且已有数据表不为空时，必须提供默认值或用 null=True + 后续填充
重命名字段或模型后需保留历史数据（RenameField 不迁移已有值，仅改名）
拆分/合并字段（如把 full_name 拆成 first_name 和 last_name）
转换字段类型（如 TextField → JSONField）且需解析/重构内容
跨模型数据聚合或迁移（如把 User 的 profile 数据迁入新 Profile 模型）

用 `makemigrations --empty` 创建可编辑的数据迁移文件

不要直接修改自动生成的迁移文件（容易被下次 makemigrations 覆盖），而是用空迁移作为数据操作载体：

运行：python manage.py makemigrations --empty myapp

生成的文件（如 migrations/0002_data_migration.py）里会包含空的 operations = []。你需要手动填入 RunPython 或 RunSQL 操作：

from django.db import migrations

def populate_new_field(apps, schema_editor):
    MyModel = apps.get_model('myapp', 'MyModel')
    for obj in MyModel.objects.filter(new_field__isnull=True):
        obj.new_field = f"computed_{obj.id}"
        obj.save()

class Migration(migrations.Migration):
    dependencies = [
        ('myapp', '0001_initial'),
    ]

    operations = [
        migrations.RunPython(populate_new_field, reverse_code=migrations.RunPython.noop),
    ]

注意：apps.get_model() 是关键——它加载迁移时刻的模型快照，避免因当前 models.py 已改动导致运行失败。