执行Django迁移遇1050错误：表'dolaposcrumy_scrumygoals'已存在

嘿，这个问题我帮好多开发者踩过坑！本质就是Django的迁移系统和你的数据库状态“不同步”——数据库里早就有dolaposcrumy_scrumygoals这张表，但Django的迁移记录还认为它需要被创建。下面分几种场景给你对应的解决办法，你可以按需选择：

场景一：这张表是多余的（不需要保留数据） #

如果这张表是之前手动创建、测试残留，或者根本用不上，直接删掉重来最省事：

• 登录你的数据库（比如MySQL用命令mysql -u 你的用户名 -p），执行SQL命令删除表：

  DROP TABLE dolaposcrumy_scrumygoals;
  

• 回到项目根目录，重新执行迁移命令：

  python manage.py migrate
  

这样Django就会按照模型定义正常创建表，同时更新迁移记录，问题解决。

场景二：需要保留表中的数据（不能删表） #

如果表里面有重要数据，绝对不能删，那就要让Django“承认”这张表已经存在：

1. 先确保你已经为模型生成了迁移文件（如果还没生成，先跑这个命令）：

   python manage.py makemigrations
   

2. 执行fake迁移，告诉Django这个app的迁移已经完成，不用再创建表：

   python manage.py migrate --fake dolaposcrumy
   

   （这里的dolaposcrumy是你的模型所在的app名称，要换成你自己的！）
3. 之后再正常执行python manage.py migrate，就不会再触发这个错误了。

场景三：迁移记录彻底混乱了（比如手动改迁移文件、多人协作冲突） #

如果上面的方法都不管用，说明迁移历史和数据库状态已经完全对不上了，那可以重置迁移流程（一定要先备份数据库！）：

1. 先备份你的数据库，防止数据丢失。
2. 找到你的app下的migrations文件夹，删掉里面除了__init__.py之外的所有迁移文件。
3. 登录数据库，删除django_migrations表中对应这个app的所有记录：

   DELETE FROM django_migrations WHERE app='dolaposcrumy';
   

4. 重新生成迁移文件：

   python manage.py makemigrations
   

5. 用--fake-initial参数执行迁移，它会自动检查数据库中是否已存在表，存在就标记迁移为已执行，不存在就创建：

   python manage.py migrate --fake-initial
   

重要提醒 #

• 生产环境操作前一定要备份数据库，别拿线上数据开玩笑！
• --fake和--fake-initial只会修改Django的迁移历史记录，不会实际修改数据库结构，所以放心用，但要确保你清楚自己的操作目的。
• 如果是团队协作项目，操作前最好和队友沟通，避免迁移记录冲突。

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