C# Entity Framework Core中的迁移(Migrations) - 数据库架构的版本控制

新闻中心 NEWS CENTER

您当前位置：首页 > 新闻中心 > 网络学院

C# Entity Framework Core中的迁移(Migrations) - 数据库架构的版本控制

2025-12-05

浏览次数：次

返回列表

迁移是EF Core数据库版本控制机制，通过add-migration生成Up/Down方法脚本，update-database执行并记录至__EFMigrationsHistory表；开发中需及时生成、检查脚本、避免冲突；生产环境应导出SQL交DBA审核，禁用业务逻辑；注意重命名、多上下文等特殊处理，确保演进可控。

c# entity framework core中的迁移(migrations) - 数据库架构的版本控制

Entity Framework Core 的迁移（Migrations）本质上是数据库架构的版本控制机制——它把模型变更记录为可执行、可回滚、可协作的代码文件，让团队能在不同环境（开发、测试、生产）中一致地演进数据库结构。

迁移如何工作：从模型到 SQL 脚本

当你修改了 C# 中的实体类或 DbContext 配置（比如新增一个属性、改字段类型、加外键），EF Core 不会自动同步数据库。你需要显式创建迁移：

add-migration 命令分析当前模型与上一次迁移快照（ModelSnapshot）的差异，生成一对 C# 文件（Up() 和 Down() 方法）
Up() 包含将数据库升级到新版本的 SQL 操作（如 ALTER TABLE、CREATE INDEX）
Down() 是逆向操作，用于回退（但某些变更如删列、改类型可能无法完全还原，需手动调整）
执行 update-database 后，EF Core 在 __EFMigrationsHistory 表中记录已应用的迁移 ID，作为“数据库当前版本”的依据

日常开发中的关键实践

避免迁移冲突和不可控变更，需遵守几个轻量但重要的习惯：

每次功能开发完成、模型定稿后立即生成迁移，不要积压多个改动再统一生成（否则 diff 易出错，Down() 逻辑难维护）
生成迁移前先运行 dotnet ef migrations remove（或 Remove-Migration）撤回未提交的本地迁移，尤其在拉取他人代码后发现迁移冲突时
检查生成的迁移文件内容——确认 SQL 是否符合预期（例如是否误删了重要列、索引是否加在正确字段上），必要时手工编辑 Up()/Down()
团队共享迁移文件（.cs + .Designer.cs + .resx），它们是源码的一部分，必须提交到 Git

处理生产环境的迁移安全策略

生产库不能直接跑 update-database，应导出 SQL 脚本交 DBA 审核：

Lateral App

整理归类论文

查看详情

用 dotnet ef migrations script（或 Script-Migration）生成完整或区间脚本，例如：dotnet ef migrations script 20251001000000_Initial 20250515120000_AddUserStatus
脚本默认包含事务包裹，失败则整体回滚；也可加 --no-transactions 适配不支持 DDL 事务的数据库（如 MySQL 旧版本）
避免在迁移中写业务逻辑（如 Sql("UPDATE ...")），这类操作难以测试、易出错；应拆到部署后的种子脚本或发布任务中

常见陷阱与绕过技巧

有些场景 EF Core 默认行为不够灵活，需要干预：

重命名列/表：EF Core 6+ 支持 HasColumnName("OldName").HasColumnName("NewName") 并自动生成 sp_rename 或 RENAME COLUMN，但老版本需手动在迁移里写原生 SQL
初始迁移已有数据库：先用 dotnet ef migrations add InitialCreate --skip-runtime 创建空迁移，再运行 dotnet ef migrations add InitialCreate -o Migrations/InitialCreate --idempotent 生成幂等脚本，最后用 update-database 标记历史表已存在
多 DbContext 共享库：每个上下文需独立的迁移文件夹（-o 指定路径）和历史表名（UseSqlServer(..., o => o.MigrationsHistoryTable("__MyAppHistory"))）