2010-06-30 70 views
4

我在我的應用程序中發現了一個問題;基本上,一個子例程準備(大量)數據,稍後通過LINQ-to-SQL數據上下文將其插入到本地數據庫中。然而,當調用SubmitChanges()時,即使相對較少量的新數據(100,000-ish)也會花費大量時間保存到數據庫中。然而,大多數情況下,應用程序更有可能節省大約20萬到30萬行。批量插入的LINQ-to-SQL性能問題

根據SQL Server的分析器,所有生成的查詢看起來都像下面那樣,並且應用程序插入的每個項目都有一個。

exec sp_executesql N'INSERT INTO [dbo].[AdjectivesExpanded]([Adjective], [Genus], [Casus], [SingularOrPlural], [Kind], [Form]) 
VALUES (@p0, @p1, @p2, @p3, @p4, @p5) 

SELECT CONVERT(BigInt,SCOPE_IDENTITY()) AS [value]',N'@p0 bigint,@p1 char(1),@p2 tinyint,@p3 bit,@p4 tinyint,@p5 nvarchar(4000)',@p0=2777,@p1='n',@p2=4,@p3=0,@p4=3,@p5=N'neugeborener' 

有沒有人有一個想法如何提高質量刀片的性能與LINQ到SQL數據上下文,理想沒有擺脫stronlgy-類型的DataContext,並回落至手寫查詢每SE?另外,調整底層數據庫幾乎沒有機會或空間。如果有的話,我可以禁用完整性約束,如果有幫助的話。

回答

2

你在做這樣的事情:

foreach (var adjective in adjectives) { 
    dataContext.AdjectivesExpanding.InsertOnSubmit(adjective) 
    dataContext.SubmitChanges(); 
} 

或者:

foreach (var adjective in adjectives) { 
    dataContext.AdjectivesExpanding.InsertOnSubmit(adjective); 
} 
dataContext.SubmitChanges(); 

如果是類似於第一個,我會建議其更改爲類似第二。每次調用SubmitChanges都會查看所有跟蹤的對象以查看發生了什麼變化。無論哪種方式,我不相信插入該卷的項目是Linq-to-Sql的一個好主意,因爲它必須每次生成和評估SQL。

你能編寫一個存儲過程的腳本並添加爲設計器的DataContext方法嗎?

+0

幾乎所有的代碼使用沿着的foreach東西線(在項目VAR項){/ * ... */dataContext.Item.InsertAllOnSubmit(...); } 但是你可能是正確的「使用LINQ到SQL進行批量插入是不好的。」如果全部失敗,我可能不得不退後使用BULK INSERT插入它們或以某種方式手動創建INSERT語句。 :-( – Manny 2010-06-30 11:04:07

+0

由此,謝謝你的存儲過程提示,它確實幫助我將存儲過程與OPENXML結合起來,這對我們來說非常有幫助,也是一個非常可行的解決方案:http://www.live.com。 codeproject.com/KB/linq/BulkOperations_LinqToSQL.aspx – Manny 2010-07-01 09:48:47

2

對於批量操作,ORM通常不是一個好主意。我會推薦一個老式的散裝插入物以獲得最佳性能。

3

查看以下頁面,瞭解如何更改代碼以使用批量插入的簡單步驟。

您只需將(提供的)BulkInsert類添加到您的代碼中,進行一些更改即可看到性能的巨大改進。

Mikes Knowledge Base - BulkInserts with LINQ