如何在Django（MariaDB环境）中回滚已应用但已删除的迁移？

我明白你现在的困境——之前自己创建的迁移已经在数据库里生效了，结果把迁移文件删了，现在代码和数据库对不上，还出了异常。结合你说的不在意数据的情况，给你两个靠谱的解决方案，优先用第一个，更符合Django的迁移逻辑：

方案一：临时恢复迁移文件进行正规回滚（推荐） #

这是最稳妥的方式，因为Django需要找到对应的迁移文件才能正确识别并回滚它的操作：

• 先从你的Git历史（或者fork仓库的记录）里把那个被删除的迁移文件找回来，放到对应app的migrations目录下，确保文件名和django_migrations表里的记录完全一致。
• 执行回滚命令，回到这个自定义迁移之前的版本：

  python manage.py migrate <appname> <previous_migration>
  

  比如你的自定义迁移是0003_custom_change，那<previous_migration>就是它之前的那个迁移名称，比如0002_old_migration。
• 回滚成功后，把这个临时恢复的迁移文件删掉就行。现在数据库的django_migrations表会自动移除这个迁移的记录，代码和数据库就完全对齐了。

方案二：无法恢复迁移文件时的强制对齐（适合不在意数据的场景） #

如果实在找不到那个迁移文件了，咱们可以手动清理数据库更改，再让Django“假装”回滚完成：

• 第一步手动撤销迁移对数据库的更改：比如这个迁移新建了表，就直接删掉表；如果是加了字段，就把字段删掉。你可以用数据库客户端执行SQL，比如：

  -- 如果是新建了表
  DROP TABLE IF EXISTS your_custom_table;
  -- 如果是添加了字段
  ALTER TABLE target_table DROP COLUMN your_added_column;
  

• 然后告诉Django更新迁移状态，假装已经回滚到之前的版本：

  python manage.py migrate --fake <appname> <previous_migration>
  

  这个命令只会修改django_migrations表的记录，不会真的执行迁移操作，刚好适合咱们这种已经手动改完数据库的情况。
• 最后验证一下状态，执行python manage.py showmigrations <appname>，你会看到所有迁移的状态都和代码里的文件一致了，没有残留的“幽灵迁移”。

注意事项 #

• 不管用哪种方案，操作前最好备份一下数据库，哪怕你说不在意数据，以防手滑出错。
• 生产环境操作前，一定要先在测试环境完整验证一遍流程！

内容的提问来源于stack exchange，提问作者CurlyError