为什么新手在Django项目中迁移MySQL表结构频繁报错？-mysql教程-PHP中文网

Django迁移失败主因是迁移文件、django_migrations表与数据库结构三者未对齐。常见错误包括删migrations文件却未清表记录、手动改库未同步状态、多环境共享数据库导致记录错位，修复须先核查三方一致性再操作。

为什么新手在django项目中迁移mysql表结构频繁报错？

因为 Django 的迁移系统依赖“迁移文件 + django_migrations 表 + 数据库真实结构”三者严格对齐，而新手常在其中任意一环手动干预，导致状态错位。

删过 migrations 文件夹但没清 django_migrations 表

这是最常见错误：本地改了 models.py，发现迁移失败，就直接删掉 app 下 migrations/ 里所有 .py 文件（除了 __init__.py），然后跑 makemigrations。但 django_migrations 表里还留着旧记录，Django 一看“这迁移我执行过了”，就不建表；可新生成的迁移又想 CREATE TABLE，MySQL 直接报 table “brand” already exists。

正确做法是先查清哪些迁移已记录：SELECT * FROM django_migrations WHERE app = 'your_app_name';
再删对应行，不是删整个表，更不能只删文件夹
如果用的是 SQLite，django_migrations 就在 db.sqlite3 里，别漏查

MySQL 中手动删表或改字段后没同步迁移状态

比如在 MySQL 客户端里直接 DROP TABLE brand;，或者用 ALTER TABLE 加了个字段，之后再跑 migrate，就会触发 django.db.utils.ProgrammingError: 1146（表不存在）——Django 认为该表该由某次迁移创建，但数据库里没了。

Django Unfold

提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。

下载

这种情况不能靠 --fake 补救，因为 fake 只标记“已执行”，不恢复结构
优先还原数据库表结构（比如从备份恢复），再让迁移对齐
若必须手动改表，改完立刻补一个空迁移：python manage.py makemigrations your_app --empty，然后在生成的文件里写上 operations = []，再 migrate 记录这次“人为变更”

多个环境共用同一份数据库或迁移文件

本地开发、测试服、甚至同事的机器，如果共享同一个 MySQL 实例，或者把 migrations/ 提交到 Git 后没处理好冲突，很容易出现“别人跑了迁移，你本地还没跑，但表已经存在”的情况。

迁移文件必须提交进 Git，但每次 makemigrations 前先 git pull，避免生成重复初始迁移
上线前务必确认 django_migrations 表和目标库结构一致，可用 python manage.py showmigrations 对比
线上环境禁止直接 makemigrations，只允许 migrate；所有模型变更必须先在本地生成迁移文件，再合入发布分支

真正难的不是命令怎么敲，而是判断“此刻哪一本账错了”。很多人卡住，是因为盯着报错信息找语法问题，却忘了先查 django_migrations 表里有没有那条记录、数据库里有没有那张表、本地 migrations/ 文件是不是和 Git 一致——这三处任何一处脱节，都会让 migrate 进入不可预测状态。