Django数据库迁移深度指南：migrate与makemigrations如何管理Schema变更（新手必读）
【免费下载链接】djangoThe Web framework for perfectionists with deadlines.项目地址: https://gitcode.com/GitHub_Trending/dj/django
Django 数据库迁移（Migrations）是管理数据库 Schema 变更的核心机制：只需makemigrations和migrate两条命令，就能把模型代码的每一次改动安全地同步到数据库。本指南面向新手，讲清这两条命令的职责、常用辅助命令与常见坑，让你彻底告别"手动改表结构"。
1️⃣ 为什么需要 Django 数据库迁移？
想象你改了一个字段：把Title从短文本变长、新增一个必填字段、或者干脆删掉一张表。数据库不会自动感知这些变化——模型代码（.py）和数据库表结构（Schema）必须保持一致，否则轻则报字段不存在，重则数据错乱。
Django 迁移的思路非常直观：
| 概念 | 类比 | 说明 |
|---|---|---|
| 迁移文件 | 数据库的"代码提交记录" | 每个.py文件描述一次 Schema 变更，按顺序编号 |
makemigrations | git diff | 对比模型与当前 Schema，生成变更脚本 |
migrate | git apply | 按顺序把迁移执行到数据库 |
所有迁移文件都集中存放在各应用的migrations/目录（例如 django/db/migrations/ 就是 Django 框架自身应用的迁移目录），团队里每个成员执行相同的迁移序列，得到的数据库结构完全一致。
2️⃣ 第一步：makemigrations 生成迁移文件
当你修改了模型（比如给Question加一个slug字段），运行：
python manage.py makemigrations它的工作流程是：
- 自动检测器（django/db/migrations/autodetector.py）对比你写好的模型定义和上一次迁移记录的 Schema 状态；
- 差异被翻译成
AddField、AlterField、CreateModel等操作对象； - 自动生成一个类似
0002_question_slug.py的迁移文件。
💡 小技巧：加--check参数只检测不写文件，适合放进 CI 检查是否有人"改了模型忘了提交迁移"。源码实现见 makemigrations.py。
上：基于模型自动生成的后台表单——模型字段一变，表单随之改变，这正是"Schema 与代码一致"的价值所在。
3️⃣ 第二步：migrate 把变更应用到数据库
python manage.py migrate这条命令"Updates database schema. Manages both apps with migrations and those without."（见 migrate.py）。它会：
- 查询数据库中的迁移记录表，找出哪些迁移已执行；
- 按依赖顺序（执行器负责）依次运行未执行的迁移；
- 每一步都在数据库事务中完成，失败可整体回滚，避免留下半成品表结构。
常用参数速查：
| 参数 | 作用 |
|---|---|
migrate polls | 只迁移polls应用 |
migrate zero | 回滚该应用的所有迁移（撤销到空状态） |
migrate --plan | 只列出将要执行的迁移，不真正执行 |
migrate --fake | 标记为已执行但不跑 SQL（适用于手工已建表场景） |
4️⃣ 三个新手救星命令
🔍showmigrations：查看迁移状态
python manage.py showmigrations每个迁移前会打[X]（已执行）或[ ]（待执行），是排查"我到底跑到哪一步了"的第一工具。源码：showmigrations.py。
🐛sqlmigrate：只看 SQL 不执行
python manage.py sqlmigrate polls 0002把指定迁移翻译成纯 SQL 打印出来——上线前"预演"表结构变更、评估锁表风险时非常有用。源码：sqlmigrate.py。
📦squashmigrations：合并历史
迁移文件积累多了（比如上百个）会拖慢初始化速度，squashmigrations能把一段历史压缩成一个文件。源码：squashmigrations.py。
5️⃣ 团队协作中的典型场景
上：Schema 同步后，后台数据列表正常展示——这正是迁移机制保障的"代码与数据库一致"效果。
- 同事 A 改了模型：他提交迁移文件，同事 B
git pull后执行migrate，本地数据库即刻对齐； - 多人同时开发冲突：如果两个迁移都叫
0003_xxx产生编号冲突，用makemigrations --merge生成合并迁移即可； - 部署新环境：全新数据库直接跑
migrate，会按 0001 → 0002 → … 顺序把全部历史迁移执行完，一步到位。
加载迁移的底层逻辑在 loader.py，它会把各应用的迁移构建成一个有向无环图（DAG），保证依赖关系正确。
6️⃣ 新手避坑清单
| ❌ 坑 | ✅ 正确做法 |
|---|---|
| 手工改数据库表后不记录 | 改动模型后用makemigrations补一个迁移 |
| 删字段/改类型时直接执行 | 先用sqlmigrate预览，大数据表评估停机时间 |
| 在迁移里写业务逻辑 | 数据迁移放在RunPython中，且必须可逆、幂等 |
| 忘记提交迁移文件 | 团队约定：改模型必须同时提交迁移 |
7️⃣ 总结：记住两条命令即可入门
📌 完整流程一句话：改模型 →makemigrations生成脚本 → 审查脚本 →migrate应用到数据库。
想深入实践，推荐阅读官方教程文档 howto/writing-migrations.txt，里面手把手演示了手写迁移、处理冲突和数据迁移；命令参数的完整定义可对照 migrate.py 与 makemigrations.py。掌握这套机制后，你的 Django 数据库 Schema 变更就像代码一样——可追踪、可回滚、可协作。
【免费下载链接】djangoThe Web framework for perfectionists with deadlines.项目地址: https://gitcode.com/GitHub_Trending/dj/django
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
