如何移除EF Core中执行超时且未成功应用的迁移？

一、废弃未应用的数据库迁移（以EF Core为例） #

由于你的迁移在开发环境未成功应用，无需回滚数据库操作，只需清理本地迁移记录与代码：

• 定位项目Migrations目录下生成的目标迁移文件（如YYYYMMDDHHMMSS_AddIndexAndFieldLength.cs及对应的.Designer.cs），直接删除。
• 打开DbContextModelSnapshot.cs，手动移除该迁移中新增的索引、字段长度限制相关代码，恢复到迁移前的模型快照状态。
• 执行命令dotnet ef migrations list确认该迁移已从列表中移除，确保本地迁移记录与开发环境数据库的__EFMigrationsHistory表（若存在）状态一致——因开发环境未应用，数据库无此记录，本地清理后即可对齐。

二、回滚代码PR的操作 #

若迁移代码已提交至PR，直接回滚完全可行：

• 找到PR对应的提交哈希值，执行git revert <commit-hash>生成反向提交，将迁移相关代码（含迁移文件、模型变更）回退至迁移前状态。
• 推送该反向提交至远程仓库，更新PR，确保PR代码恢复到迁移前版本。
• 若PR未合并，也可直接关闭或替换分支内容，但git revert能保留完整操作记录，更便于团队追溯。

三、后续替代方案补充建议 #

• 手动添加索引：若选择此方案，先确保开发环境数据库与本地一致，在Azure SQL查询编辑器中执行CREATE INDEX语句时，添加ONLINE = ON参数（Azure SQL支持的版本），可避免长时间锁表，降低DTU占用超时概率。
• 调整超时时间：若想尝试让迁移通过，可在EF Core的AddDbContext配置中修改命令超时：

  optionsBuilder.UseSqlServer(connectionString, options =>
      options.CommandTimeout(300)); // 按需设置超时时长，示例为300秒
  

  但10个DTU的环境资源有限，即使延长超时，仍可能因资源不足失败，建议结合手动索引方案。
• 重建数据库：若开发环境数据无保留价值，直接从本地备份还原或重新初始化数据库效率最高，但需同步团队成员操作，避免数据不一致。

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