EF Code First突发数据库与模型失同步 报master库建表权限错误

该故障核心是EF Code First的迁移状态判定逻辑完全失效，结合报错指向master库的特征，触发原因按概率从高到低排序：

• 连接配置异常（最高概率）：当前应用、迁移命令使用的数据库连接，实际指向了SQL Server的master系统库而非业务库。
  这种无代码、无部署变更的突发故障，最常见的诱因是IT/运维侧调整SQL账号属性时，把业务访问账号的默认数据库从业务库改成了master，而原有连接串恰好没配置Initial Catalog=业务库名参数——之前靠账号默认库能正常连业务库，调整后所有连接默认进master，EF在master里找不到迁移历史表，就会判定当前是未初始化的全新库，直接触发全量建表逻辑，自然会抛出master库建表权限不足的错误。
• 迁移历史表异常：业务库内的__MigrationHistory系统表被误删、或业务访问账号被收回了该表的读取权限。
  这张表是EF识别库结构和模型匹配度的唯一依据，一旦EF读不到这张表的内容，就会判定数据库和当前模型完全失同步，执行add-migration时就会生成覆盖全库所有表、列、外键的全量建表脚本。如果同时存在连接串指向master的问题，就会完全复现你遇到的报错。
• 迁移初始化策略被篡改：代码中EF的数据库初始化器被从原有迁移策略改成了CreateDatabaseIfNotExists，但你提到未更新部署内容，该场景概率极低。

1. 优先核对连接配置正确性
   逐一检查生产、测试环境web.config、VS包管理器控制台默认指向的启动项目配置文件内的数据库连接串，确认三个核心参数正确：SQL实例地址正确、Initial Catalog明确填写业务库全名、访问账号密码正确。同时登录SQL Server实例检查业务访问账号的属性，将其默认数据库改回对应业务库，不要保留默认的master配置。
   验证方式：用连接串内的账号密码手动登录SQL，执行SELECT DB_NAME()确认当前会话默认落在业务库，而非master。
2. 检查迁移历史表状态
   用数据库管理员账号登录业务库，在系统表分类下查找__MigrationHistory表：
   • 如果表存在：检查业务访问账号是否拥有该表的SELECT权限，权限缺失直接补全即可
   • 如果表被误删：不要执行异常生成的全量迁移脚本，先从最近一次正常运行时间点的数据库备份中，把__MigrationHistory表的全量数据恢复到当前业务库，恢复后EF就能重新识别到已有的迁移记录
3. 验证同步状态
   修正连接配置、恢复迁移历史表后，先在测试环境执行Add-Migration TestSync验证：如果生成的迁移文件是空的（没有重复创建已存在对象的逻辑），说明库和模型已经恢复同步，此时再执行update-database确认无报错，最后再在生产环境执行相同修复操作即可。

注意：严禁在生产环境直接执行故障状态下生成的全量迁移脚本，否则会触发表重复创建、数据覆盖等不可逆的生产事故。

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