LINQ查詢的效果分析
使用LINQ查詢時(shí)數(shù)據(jù)操作的性能是如何的呢？我們在進(jìn)行LINQ查詢的使用時(shí)會有什么效果呢？那么這里就向你提供一點(diǎn)對于LINQ查詢時(shí)的數(shù)據(jù)操作的性能相關(guān)介紹。
LINQ查詢的一點(diǎn)體會
當(dāng)我們會熟練的使用以上的查詢方法對數(shù)據(jù)庫里的內(nèi)容做各種各樣的查詢以后，就應(yīng)當(dāng)要了解這些數(shù)據(jù)庫操作的機(jī)制，及時(shí)調(diào)整各種數(shù)據(jù)操作語句，以較高的效率運(yùn)行。那么，下面我們來看看LINQ的數(shù)據(jù)庫操作，看看她都做了些什么工作。
與NHibernate來比較，LINQ在O/R Mapping的性能與可控性上確實(shí)優(yōu)于NHibernate，首先，Linq默認(rèn)的數(shù)據(jù)映射采用的是Attribute來實(shí)現(xiàn)，這是.NET特有的語法，在編譯時(shí)就已經(jīng)決定了數(shù)據(jù)對象的各種屬性，而NHibernate等大多數(shù)O/RMapping工具仍然采用XML映射文件來描述數(shù)據(jù)對象的屬性，從外部文件上讀取數(shù)據(jù)對象的屬性，顯然運(yùn)行時(shí)效率要有所損失。其次,在獲得數(shù)據(jù)的方式上也有所差別，LINQ中強(qiáng)大的SQL分析機(jī)制，可以分析出各種數(shù)據(jù)操作的SQL語句，并且進(jìn)行優(yōu)化，其效率的提升也是顯而易見的。
當(dāng)然，作為一個(gè)O/R Mapping的工具來說，其效率一定達(dá)不到直接使用SQL語句訪問數(shù)據(jù)庫的效率，也就是我們通常所說的SqlDataReader/SqlDataAdapter訪問數(shù)據(jù)庫，但是，Linq的表現(xiàn)卻給了我們非常大的驚喜，我做了一個(gè)測試，使用SqlDataReader和LINQ做相同的大批量數(shù)據(jù)查詢時(shí)，落后竟然不到10%，而NHibernate的查詢效率，卻低了很多，幾乎慢了1倍。對于如此強(qiáng)大的數(shù)據(jù)映射功能，這樣的效率是我們可以接受的。但是很可惜的一點(diǎn)是，LINQ目前只能支持對SQLServer的支持（但可以支持XML、Entity等）。
在使用LINQ查詢進(jìn)行數(shù)據(jù)查詢上，我們通過對LINQ生成的SQL語句進(jìn)行分析，便可以優(yōu)化查詢，這是非常方便的，但是，針對數(shù)據(jù)更新的效率問題，我們不得不談?wù)凩INQ的數(shù)據(jù)更新機(jī)制，一般情況下，數(shù)據(jù)更新我們會這么做：
- var query = from emp in dbdata.Employees
- where emp.DepId=="1001" select emp;
- Employee employee = query.First();
- employee.EmployeeName = "李四";
- dbdata.SubmitChanges();
對于以上這段代碼，我們可以看出，其功能是從Employee表中取出部門代碼為1001的所有員工，然后我們?nèi)〕?**條數(shù)據(jù)（這里為了簡便，我們僅僅取出***條，其實(shí)可以用Where取出滿足條件的記錄），然后把名字修改成“李四”，再更新到數(shù)據(jù)庫中。這段代碼，LINQ都干了些什么呢？通過查詢從數(shù)據(jù)庫中取出若干條記錄，放在內(nèi)存中，并且都標(biāo)記為new（未改變）狀態(tài)，當(dāng)修改了員工姓名的時(shí)候，被修改的對象被標(biāo)記為Dirty(已改變),在SubmitChanges的時(shí)候，再為內(nèi)存中對象狀態(tài)為Dirty的記錄自動生成SQL語句并執(zhí)行，也就是說，我們要完成一次數(shù)據(jù)的更新，至少要完成一次查詢和一次更新。
LINQ查詢的一點(diǎn)分析：
由于采用了延時(shí)加載（Layze Load）的技術(shù)，在以上語句中實(shí)際從數(shù)據(jù)庫中取出的記錄只有1條，更新的時(shí)候也只更新這一條，因此效率仍然是非常高的，我在測試的過程中發(fā)現(xiàn)，從250000條數(shù)據(jù)中隨機(jī)抽取一條進(jìn)行更新，實(shí)際的效率和從10條數(shù)據(jù)中隨機(jī)抽取一條進(jìn)行更新幾乎沒有差別，因?yàn)楸容^更新狀態(tài)是在內(nèi)存中進(jìn)行，因此效率是比較高的。下面我們再看看實(shí)際的更新生成了什么樣的SQL語句：
- UPDATE [dbo].[Employee] SET [EmployeeName] =
- @p4 WHERE ([EmployeeId] = @p0) AND ([DepId] = @p1) AND
- ([EmployeeName] = @p2) AND ([EmployeeSalary] = @p3)
原來，我們只修改了EmployeeName的字段，生成的SQL語句卻也僅僅是更新了Employee字段。那么，我們再看看后面的條件，為什么會包含除了主鍵以外的其他條件呢？原來，這也是LINQ自動生成SQL語句的嚴(yán)謹(jǐn)所在，這是為了防止并發(fā)情況下，多個(gè)事務(wù)針對同一條記錄更新時(shí)發(fā)生錯(cuò)誤，假如A事務(wù)更新了該記錄，則B事務(wù)更新會失敗。我們不禁要問，假如要更新主鍵字段怎么辦？會不會錯(cuò)誤的更新到多條記錄呢？答案是肯定的，肯定會錯(cuò)誤的更新到其他記錄，因此，LINQ中規(guī)定了主鍵字段是不允許更新的，如果確實(shí)要更新，那么就刪除掉該記錄，重新插入新紀(jì)錄。這么嚴(yán)謹(jǐn)?shù)腟QL語句，會給我們帶來一些麻煩，我們來看下面一個(gè)應(yīng)用場景：
如果我們在表中設(shè)有一個(gè)字段用于計(jì)數(shù)器，使用SQL語句是這樣的：
- Update CountTable set CountColumn=
- CountColumn+1 where CountId=@countId
但使用LINQ生成的Sql語句卻是：
- UPDATE [dbo].[CountTable] SET [CountColumn] = @p2
- WHERE ([CountId] = @p0) AND ([CountColumn] = @p1)
@p2這個(gè)參數(shù)是計(jì)算好后傳入的，@p1這個(gè)參數(shù)是CountColumn原來的值。也就是說，CountColumn+1這個(gè)值不是由數(shù)據(jù)庫運(yùn)算出來的，這樣一來，當(dāng)并發(fā)數(shù)很高的時(shí)候，我們往往會更新失敗。我做了個(gè)測試，使用多線程模擬多用戶的情況下進(jìn)行計(jì)數(shù)統(tǒng)計(jì)，數(shù)據(jù)庫中統(tǒng)計(jì)的值比使用靜態(tài)變量保存的值要小，這也就是說數(shù)據(jù)庫更新是存在失敗的情況。另外，這樣每次的更新，需要完成的操作有查找和更新兩個(gè)步驟，因此對于效率也有比較大的影響。
在這里，我們并不是要說明LINQ存在缺陷，因?yàn)檫@種情況可能在任何的O/R Mapping的框架下都得不到很好的解決，這里僅僅是想告訴我們，只有了解系統(tǒng)內(nèi)部運(yùn)行的情況，才能設(shè)計(jì)出效率更高，更可靠的系統(tǒng)。
關(guān)于使用LINQ查詢的相關(guān)內(nèi)容就向你介紹到這里，希望對你了解和學(xué)習(xí)LINQ查詢有所幫助。
【編輯推薦】
