本文分享了一次针对EF MySQL批量插入多表数据的性能优化经验。通过分批读取、减少SaveChanges次数和优化事务使用，将400000订单的迁移时间从分钟级降至小时级。主要措施包括：批量查询数据、分三次插入并利用EF的数据追踪功能、控制事务范围以及避免在单一DbContext中多次SaveChange。
距离上次的博客已经有15个多月了，感慨有些事情还是需要坚持，一旦停下来很有可能就会停很久或者从此再也不会坚持。但我个人一直还坚持认为属于技术狂热份子，且喜欢精益求精的那种。最近遇到两个和数据迁移相关的项目，均遇到需要性能优化的问题，这里拿第二个项目的一个小优化过程与大家分享，技术并不高深，我注重的是解决问题的过程。我的方案是有业务背景以及技术背景限制的，不一定适合其它项目，优化是相对的。
业务场景：我们需要迁移一批老的合同订单数据，其有一个合同的订单数为519条，迁移到新表中会涉及到主要的4个表，就是说519条老数据，会变成519*4。
技术背景：数据库是mysql,后台采用的是微软的EF
问题：迁移这批订单当时最好的性能方案是14秒(未优化前是分钟级别)，我们总共有400000订单，算下最理想状态下的总时间：=(14/519)*400000/3600=3小时，再算下取数据，转换数据的时间，基本要4小时。如果中途有异常，这个时间可能需要一夜甚至更长的时间才能迁移完，这真正恶梦。<
最低0.47元/天 解锁文章
扫一扫
159
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
