LINQ-To-Sql 更新 - 性能问题
我有一个包含 230 列和 1200 万行的表。
我需要更新每行的 123 个字段。
如果我尝试使用 LINQ-To-Sql 执行此操作，则会出现 System.OutOfMemory 异常。
我知道如果禁用对象跟踪，我不会收到 OutofMemory 错误。 但我认为如果禁用对象跟踪，我将无法执行更新。
更新它们的最佳方法是什么？
I have a table which includes 230 columns and 12 million rows.
I need to update 123 fields of EACH row.
If I try to do it with LINQ-To-Sql, I get System.OutOfMemory Exception.
I know I don't get OutofMemory error if I disable object tracking.
But I think I cannot perform updates if I disable object tracking.
What is the best way to update them?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这不是一个适合 LINQ-to-SQL 的任务，或者坦率地说任何 ORM。您不想想要以这种方式在网络上拖动那么多数据两次；理想情况下，应该用纯 TSQL 编写，如果需要与其他来源的数据合并，也许可以使用批量插入/SqlBulkCopy 来填充单独的表。
That is not a task suitable for LINQ-to-SQL, or frankly any ORM. You do not want to drag that much data twice over the network in that way; that should ideally be written in pure TSQL, perhaps using bulk insert /
SqlBulkCopyto populate a separate table if you need to combine with data from other sources.我肯定会建议你改变架构，将大表解耦成几个小表，并且绝对避免对这种数据量使用 linq-to-sql。
以这样的方式创建架构，即为业务级别的每个实体提供类，这些类将调用 T-SQL 查询的存储过程来更新数据访问级别的数据。
I would definitely suggest that you change the architecture, decouple the big table into several small ones and definitely avoid linq-to-sql for this amount of data.
Create the architecture in that way that you have classes for each entity on a business level that will call stored procedures of T-SQL queries to update the data on data access level.