EF Code-First下将大表8个nvarchar(max)列改为varchar(x)的方案咨询

原方案合理性确认 #

你的分步思路是处理大表Schema变更的典型稳妥方案，避开了EF直接执行大表DDL的性能瓶颈，核心是把耗时的数据迁移环节交给DBA掌控，将Schema变更拆分为轻量操作，这个方向完全没问题。

各步骤的细节补充 #

步骤1：创建新表T2 #

• 除了调整列类型为varchar(100)等，必须同步T1的所有约束与索引：主键、外键、唯一约束、默认值、非空属性，以及所有业务依赖的索引（包括覆盖索引、联合索引），避免数据迁移后出现查询性能下降或约束冲突。
• 如果T1包含自增列，T2的对应列要设置完全相同的自增种子和增量值，确保数据导入后ID序列连贯。
• 先在测试环境1:1复刻T1的结构与全量数据，验证T2的结构正确性，重点检查原nvarchar(max)列转目标类型后的数据完整性（比如是否有数据截断）。

步骤2：DBA执行数据迁移（停机环节） #

• 停机前必须完成全量数据库备份，且要验证备份的可恢复性，这是生产操作的底线。
• 数据迁移优先用批量操作：比如SQL Server的bcp工具、INSERT INTO ... SELECT ...分批执行（每批次10万-50万条），避免一次性加载全量数据导致事务日志暴涨。如果是SQL Server，可临时将T2所在数据库切换为批量日志恢复模式，大幅减少日志生成量。
• 迁移完成后强制做数据校验：对比T1与T2的总行数，抽样检查关键列内容（尤其是类型变更的列），确认无数据丢失或截断。

步骤3-5：重命名表的Schema变更 #

• 生成EF迁移文件后，务必手动检查脚本内容，确保只有sp_rename（或对应数据库的重命名语句）操作，剔除EF自动生成的冗余DDL（比如不必要的约束重建）。
• DBA执行重命名前，要确认所有应用连接已完全断开（停机状态下），避免有进程正在读写T1/T2导致重命名锁等待或失败。
• 重命名完成后，用dotnet ef migrations script生成对比脚本，验证EF模型与数据库状态完全一致，再执行本地迁移步骤，保证Code-First的迁移历史与数据库状态同步。

步骤6-8：删除原表T1 #

• 删除前要彻底排查依赖：确认没有视图、存储过程、外键约束还关联T1，同时EF模型中已完全移除对T1的引用。
• DBA执行删除后，不要立即清理迁移历史，先观察应用运行24小时以上，确认无异常后再做后续清理。

额外优化建议 #

• 若停机时间要求严格，可采用双写过渡方案：步骤1完成后，修改应用代码同时写入T1和T2，在非高峰时段做增量数据同步（比如基于时间戳或自增ID同步新增/更新数据），最后切换为只写T2，再停机做最终一致性校验与重命名，可将停机时间压缩至数分钟。
• 针对EF迁移历史：每次DBA手动执行脚本后，需确保__EFMigrationsHistory表中对应的迁移记录被正确插入（可手动插入或执行迁移时加-IgnoreChanges参数，让EF仅记录迁移历史不执行实际操作），避免后续迁移出现状态不一致。
• 迁移过程中全程监控数据库的CPU、内存、磁盘IO、事务日志增长情况，一旦出现异常立即暂停排查，避免引发生产事故。

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