Azure App Service中ASP.NET Core初始化脚本异常及优化方案咨询

一、解决Main方法被Azure重启的核心思路 #

Azure App Service对应用启动流程有严格的超时限制（默认230秒），如果Main方法或启动阶段（比如Program.cs初始化、Startup配置逻辑）里执行长时间运行的任务，一旦超时就会触发应用重启，这就是你遇到skipAmount归零的原因。要避免这个问题，核心是把长耗时任务移出应用启动流程，具体可以这么做：

• 绝对不要在启动逻辑里阻塞执行长任务：应用启动的唯一目的是让Web服务尽快就绪、接受请求，任何超过几秒的操作都不该放在这里。
• 用后台异步任务触发迁移：如果需要在应用启动后自动执行迁移，使用ASP.NET Core的BackgroundService（实现IHostedService），让迁移任务在后台异步运行，不阻塞应用启动流程。同时必须给任务加状态持久化：比如在数据库里建一个简单的迁移状态表，记录当前处理到的批次ID或最后一条记录的ID，每次启动后台任务时先读取这个状态，处理完一批就更新状态。就算应用中途重启，也能从上次中断的位置继续，不会从头开始。
• 临时调整启动超时（不推荐）：如果实在要在启动阶段跑任务，可以在Azure门户的App Service「配置」→「常规设置」里调整启动超时时间（最大支持1800秒），但这只是权宜之计，无法解决应用回收、意外重启导致的任务中断问题。

二、更优的数据迁移方案 #

你现在用CQRS命令+Postman触发的方式虽然解决了重启问题，但47分钟的耗时还是太长，推荐以下几种更高效的方案：

• 用EF Core批量操作库：替换逐条插入的逻辑，使用EF Core Bulk Extensions这类第三方库，支持批量查询、批量插入、批量更新，能把迁移时间压缩到几分钟甚至更短。比如读取一批数据后，直接调用context.BulkInsert()，比循环调用Add+SaveChanges效率高几个数量级。
• 脱离Web应用执行迁移：把迁移逻辑做成独立的控制台应用，部署到Azure VM、Azure Container Apps，或者用Azure Functions手动触发。这样迁移任务和Web应用完全隔离，不会占用Web应用的资源，也不会因为Web应用的重启影响迁移进度。
• 用数据库原生工具：如果源和目标数据库是同类型（比如都是SQL Server），直接用数据库原生工具迁移：
  • SQL Server可以用「导入导出向导」、bcp命令行工具，或者Azure Data Factory做数据复制，这是数据库级别的操作，绕过了应用层的开销，速度最快。
  • 如果是不同类型数据库，也可以用Azure Data Factory做跨库迁移，配置好数据源和目标，一键触发即可。
• 优化分批逻辑：如果坚持用代码处理，不要用Skip(n).Take(batchSize)，因为Skip在大数据集上性能很差。改成按记录的ID分段：比如每次取ID大于上次最大ID的前N条记录，这样查询效率更高，同时把上次的最大ID存在数据库或Azure Storage里，就算重启也能继续。

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