EntityFramework Core 迁移脚本中引用已删除列的问题解析

问题背景

在使用 EntityFramework Core 进行数据库迁移时，开发人员可能会遇到一个典型问题：在自定义迁移脚本中引用了已被删除的数据库列。这种情况通常发生在以下场景：

1. 开发人员创建了一个包含特定列（如 Status 列）的迁移
2. 后续迁移中删除了另一个列（如 EndDate 列）
3. 但早期迁移中的 SQL 脚本仍然保留了对已删除列的引用

问题表现

当 CI/CD 管道生成迁移脚本时，EF Core 会将所有迁移打包成一个完整的 SQL 脚本。即使某些代码逻辑上不会执行（如被 IF 条件包裹），脚本中仍然会包含对已删除列的引用，导致执行失败。

解决方案

推荐方案：使用动态 SQL

最可靠且推荐的方法是使用 EXEC sp_executesql 执行动态 SQL。这种方式可以：

• 延迟 SQL 语句的解析到实际执行时刻
• 避免脚本生成时检查列是否存在
• 保持迁移历史记录的完整性

EXEC sp_executesql N'
UPDATE TableName
   SET [Status] = ''Suspended''
 WHERE [Status] IS NULL
   AND (GETDATE() > EndDate)
   AND (GETDATE() < DATEADD(D, 60, EndDate));
'

其他注意事项

1. 迁移脚本的幂等性：确保迁移脚本可以安全地多次执行，通常通过检查 __EFMigrationsHistory 表实现

2. SQL 注入防护：当使用动态 SQL 时，特别是包含参数时，应使用参数化查询而非字符串拼接

3. 迁移顺序：理解 EF Core 按时间顺序应用迁移的机制，避免跨迁移的列依赖

最佳实践

1. 最小化自定义 SQL：尽量使用 EF Core 的迁移 API 而非原始 SQL

2. 及时清理：删除不再需要的迁移或更新旧迁移中的 SQL 脚本

3. 测试验证：在 CI/CD 流程中加入迁移脚本的测试环节

4. 文档记录：对必须使用动态 SQL 的情况添加注释说明原因

技术原理

EF Core 的迁移系统在生成 SQL 脚本时会对整个迁移历史进行静态分析，而不会考虑运行时条件。因此即使代码逻辑上不会执行，对已删除列的引用仍会导致问题。动态 SQL 通过将解析推迟到执行时解决了这个问题。

通过理解这些原理和采用推荐实践，开发人员可以更安全地管理 EF Core 数据库迁移过程。