基于C#/.NET/EF Core/SQL的生产数据库迁移技术疑问与方案咨询

问题1：script migration -idempotent生成的脚本能否直接用MSSMS/VS SQL Server Explorer执行？ #

明确说：完全可以。DbUp、Flyway这类工具的核心价值是提供自动化流水线、版本追踪、回滚机制、批量执行管控，并非只有它们能运行这类脚本。

手动执行时要注意这几点：

• 执行前必须备份生产数据库，避免不可逆错误
• 先在测试环境完整跑一遍脚本，确认无语法或逻辑问题
• 脚本本身自带幂等逻辑（会检查__EFMigrationsHistory表记录），不用担心重复执行
• 确保执行账号有足够的数据库权限（如DDL权限），但别用sa这类超级账号
• 尽量选业务低峰期执行，减少对线上业务的影响

问题2：用控制台应用调用context.Database.Migrate触发生产环境迁移是否可行？实际逻辑是什么？ #

只要控制台应用的连接字符串指向生产数据库，完全能影响生产系统，这是实打实的生产库操作，并非模拟。

实际逻辑很直接：

1. 控制台应用启动后，EF Core会加载项目中所有已定义的迁移文件
2. 连接目标数据库，读取__EFMigrationsHistory表中的已执行迁移记录
3. 对比本地迁移和已执行记录，将未应用的迁移依次执行到数据库中

生产环境用这个方式的注意事项：

• 严格控制控制台应用的部署和执行权限，避免误操作
• 优先选择在应用停服时执行迁移，防止迁移过程中业务读写导致的数据不一致（比如添加必填列时，业务写入可能失败）
• 如果要在应用运行中执行，必须保证迁移是非破坏性、无锁的（比如添加非必填列、创建索引），绝对不能做删除列、修改主键这类高危操作
• 一定要加日志输出，记录迁移的每一步执行状态，方便排查问题

问题3：SQL基础尚可，是否推荐用SQL对比工具生成脚本做迁移？ #

非常推荐，但要结合场景使用。这种方式的优势很明显：

• 对SQL熟悉的话，能精准控制迁移的每一个细节，比如优化索引创建顺序、分批处理大表的数据迁移，避免EF Core自动生成脚本可能出现的性能问题
• 适合复杂迁移场景，比如表拆分、数据清洗、历史数据归档这类EF Core难以自动处理的操作
• 脚本可读性强，方便团队评审和修改

但也要注意弥补它的短板：

• 必须自己实现幂等逻辑（比如每个DDL操作前加IF NOT EXISTS (...)判断），防止重复执行出错
• 要手动维护迁移版本记录，比如在脚本开头标注版本号，或者自己维护一个类似__EFMigrationsHistory的版本表
• 所有脚本必须纳入代码仓库管理，和项目代码一起做版本控制
• 执行前一定要在测试环境反复验证，尤其是涉及数据变更的脚本

不管选哪种迁移方案，都要遵守这些原则：

• 测试环境1:1复刻生产环境的数据库结构和数据量，所有迁移必须先在测试环境验证通过
• 每次生产迁移前，强制做全量数据库备份
• 小步迭代，一次只做一类迁移（比如只加列，不同时改索引），避免一次操作太多导致回滚困难
• 所有迁移操作都要留痕，记录版本号、执行时间、执行人员，方便出现问题时快速定位和回滚
• 生产环境迁移必须选业务低峰期，提前通知相关团队做好应急预案

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