在Django项目开发中，执行完数据库迁移后仍然遇到INTEGRITY ERROR，且提示目标列已不存在，是很多开发者都会碰到的典型问题。这类问题通常并非业务逻辑错误，而是数据库迁移记录、实际表结构与模型定义三者不一致导致的。
问题常见成因
要解决问题首先需要明确可能的触发原因，常见的有以下几种情况：
- 手动修改过数据库表结构，没有同步更新Django的迁移文件
- 迁移文件被误删、修改或者存在依赖缺失的情况
- 多次执行迁移后，django_migrations表中的记录与实际迁移文件不匹配
- 模型字段删除后，相关的外键约束或者索引没有被正确清理
排查步骤
第一步：确认模型与迁移文件一致性
首先检查当前模型的字段定义，确认报错的列是否已经在模型中移除。然后查看项目的migrations目录下，是否存在对应的迁移文件记录。
可以使用以下命令查看当前迁移状态：
python manage.py showmigrations
第二步：检查数据库实际表结构
直接连接数据库，查看对应表的字段列表，确认报错的列是否真的已经不存在。以MySQL为例，查看表结构的命令如下：
-- 查看表的所有字段 DESCRIBE 你的表名;
第三步：核对迁移记录表
查看数据库中的django_migrations表，确认所有已应用的迁移文件是否都正确记录在表中：
-- 查看所有已应用的迁移 SELECT * FROM django_migrations;
解决方案
方案一：重建迁移文件（适用于开发环境）
如果是开发环境，且可以接受清空数据库数据，可以按照以下步骤操作：
- 删除项目migrations目录下所有除__init__.py之外的迁移文件
- 清空数据库中所有表，尤其是django_migrations表
- 重新生成迁移文件并执行迁移：
python manage.py makemigrations python manage.py migrate
方案二：手动修复迁移记录（适用于生产环境）
如果是生产环境，不能清空数据，需要先备份数据库，然后执行以下步骤：
- 找到最后一条正确应用的迁移文件，记录其名称
- 删除django_migrations表中，在最后一条正确迁移之后的所有记录
- 将模型中已经删除的字段对应的迁移操作，手动标记为已应用：
python manage.py migrate --fake 你的应用名 迁移文件名
方案三：清理残留约束
如果是因为残留的外键约束或者索引导致的报错，需要手动在数据库中删除对应的约束。比如删除外键约束的命令如下：
-- MySQL删除外键约束示例 ALTER TABLE 你的表名 DROP FOREIGN KEY 外键约束名;
预防措施
为了避免再次出现这类问题，建议遵循以下规范：
- 不要手动修改数据库表结构，所有表变更都通过Django迁移完成
- 不要随意删除或者修改已有的迁移文件，尤其是已经应用到生产环境的迁移文件
- 每次修改模型后，及时执行makemigrations和migrate命令，并且提交迁移文件到版本控制
- 生产环境执行迁移前，先在测试环境验证迁移的正确性
按照上述步骤排查和修复，基本可以解决Django迁移后INTEGRITY ERROR提示列不存在的问题，保证项目数据库状态与模型定义保持一致。
DjangomigrationINTEGRITY_ERRORdatabase_migration修改时间：2026-06-26 00:39:12