Django执行migrate时触发InconsistentMigrationHistory错误求助

InconsistentMigrationHistory 触发的核心原因是迁移线性依赖校验失败：你的数据库django_migrations表中已经存在0006迁移的应用记录，但它的前置依赖0005迁移没有对应记录，Django不允许这种断档存在，之前的修复操作没生效，本质是没有先修正表里错误的迁移标记。

操作前先备份数据库，避免误操作导致数据丢失。

• 连接你的数据库，执行SQL删除customerweb应用下0005及之后的错误迁移记录：

DELETE FROM django_migrations WHERE app = 'customerweb' AND name >= '0005_auto_20220614_1100';

该操作仅删除迁移版本记录，不会修改业务表中的实际数据，不要手动删除任何业务表。

• 检查customerweb/migrations目录，确保0001到0007的迁移文件完整存在。如果之前删除过迁移文件，从代码仓库恢复即可，仅保留__init__.py会导致后续迁移重复执行建表/加字段逻辑，触发新的报错。
• 按顺序标记已实际生效的迁移为已应用：由于0006已经存在应用记录，说明0005、0006的表结构变更已经同步到数据库，不需要重复执行SQL，直接用fake标记即可：

# 标记0005已应用
python ./manage.py migrate customerweb 0005_auto_20220614_1100 --fake
# 标记0006已应用
python ./manage.py migrate customerweb 0006_orderdelivery_is_order_unique --fake

• 执行正常迁移命令，同步未应用的0007迁移：

python ./manage.py migrate

迁移执行完成后，运行python ./manage.py showmigrations customerweb，确认所有迁移项前都显示[X]，即修复完成。

• 之前--fake参数不生效，是因为Django在执行迁移前会先做全局依赖校验，发现0005缺失时会直接抛错，根本不会走到后续的fake逻辑。
• 非必要不要删除migrations目录下的历史迁移文件，迁移文件和数据库结构是强绑定关系，随意删除会直接破坏迁移依赖链。

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