Django数据库更新命令有哪些？

发布时间:2025-09-26 00:09

下面给你一份“可执行、可回滚、可审计”的 Django 数据库更新命令矩阵。聚焦两类更新：结构迁移（schema） 与 数据迁移（data），并覆盖“检查→执行→回滚→排障→加固”的全链路。🚀

1) 开发前置：变更检查与计划

# 仅检测是否需要新迁移文件（CI 常用，返回码可用于阻断发布）
python manage.py makemigrations --check

# 预演要生成的迁移，不落盘
python manage.py makemigrations --dry-run -v 3

# 解决多人分支并发导致的迁移冲突
python manage.py makemigrations --merge
​

• --check 与 --dry-run 用于“左移质量”，在提交前发现遗漏迁移；--merge 生成合并迁移，解决并发冲突。(django.readthedocs.io)

# 按执行顺序查看迁移计划（上云前必查）
python manage.py showmigrations --plan
​

• --plan 让“将要执行什么”一目了然，避免线上“误更表”。(fig.io)

# 预览某个迁移对应的 SQL（适合 DBA 复核）
python manage.py sqlmigrate app_label 0005_add_index
​

• sqlmigrate 可正/反向生成 SQL 以供审阅与变更评审。(fig.io)

2) 标准执行：结构迁移（Schema）

# 生成迁移
python manage.py makemigrations

# 应用全部迁移到“默认库”
python manage.py migrate

# 指定库或指定 App
python manage.py migrate --database=analytics app_label
​

• 生产分库时用 --database 精准下发，降低跨库误操作风险。官方 migrate 支持 --fake / --fake-initial 等高级参数（见下）。(fig.io)

特殊场景：

# 目标库已有同名表，首次接入迁移框架时常用
python manage.py migrate --fake-initial

# 手动修表或 DBA 已执行 SQL，需要仅同步“迁移状态”
python manage.py migrate app_label 0005 --fake
​

• --fake-initial 用于“既有表首次纳管”；--fake 用于“状态对齐”。使用前务必确认实际表结构与迁移一致。(fig.io)

3) 数据迁移（Data Migration）：安全变更数据

# 生成空迁移文件，编写数据迁移逻辑
python manage.py makemigrations --empty app_label
​

• 在空迁移中编写 RunPython / RunSQL 操作，完成批量数据修复、回填等。(Django Project)

事务与大表注意：

• 对支持 DDL 事务的库（如 PostgreSQL、SQLite），迁移默认包裹在单事务内；不支持 DDL 事务的库（如 MySQL、Oracle）行为不同。必要时在迁移类设置 atomic = False，或对 RunPython 指定 atomic=True/False，以获得更灵活的事务边界（大表分批更稳）。(Django Project)

4) 回滚与清理（发生故障/灰度撤回）

# 回滚到指定版本
python manage.py migrate app_label 0003

# 清空某个 App 的所有迁移（慎用）
python manage.py migrate app_label zero
​

• 回滚前先用 showmigrations --plan 复核依赖链，避免“牵一发而动全身”。(fig.io)

数据层面配套：

# 只输出清库 SQL，不直接执行（审阅后再用 DBA 通道）
python manage.py sqlflush

# 快照/回填数据（配合迁移窗口使用）
python manage.py dumpdata > data.json
python manage.py loaddata data.json
​

• dumpdata/loaddata 适合“小规模业务字典或基础配置”快照回填，避免将其当作通用备份工具。

5) 排障与数据库直连

# 直接进入目标库执行只读校验或索引检查
python manage.py dbshell --database=default
​

• 与 sqlmigrate 联合使用，快速完成“生成 SQL → 实库校验”的闭环。(Django Project)

6) 发布级最佳实践（落地即稳）✨

• 三板斧：makemigrations --check（阻断遗漏）→ showmigrations --plan（确认路径）→ sqlmigrate（SQL 复核）。(django.readthedocs.io)
• 多人协作：遇到迁移编号冲突先 --merge，严禁直接手改已有迁移文件。(django.readthedocs.io)
• 老库纳管：首发用 --fake-initial；若 DBA 先行改表，再用 --fake 对齐状态。(fig.io)
• 大表/长事务：数据迁移内使用 atomic=False+分批（如分页处理、批量提交），降低锁表与回滚成本。(Django Project)
• 多库治理：强制在 CI/CD 中显式传 --database，并为不同库设置独立迁移阶段与回滚剧本。
• 可观测：将迁移日志纳入发布审计，搭配慢 SQL 报警与表膨胀监控，形成变更闭环。📈

一句话结论：把上述命令沉淀为“发布前置清单 + 执行脚本 + 回滚预案”，你的迁移就能实现 可预演、可核验、可回退，既提速上线又降低风险。需要的话，我可以按你的项目结构输出“CI 版迁移脚本模板”和“数据迁移示例（分批回填）”。💡