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