本篇內(nèi)容介紹了“LINQ查詢的效果舉例分析”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

成都創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于做網(wǎng)站、網(wǎng)站制作、龍勝網(wǎng)絡(luò)推廣、微信平臺小程序開發(fā)、龍勝網(wǎng)絡(luò)營銷、龍勝企業(yè)策劃、龍勝品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；成都創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供龍勝建站搭建服務(wù)，24小時服務(wù)熱線：13518219792，官方網(wǎng)址：www.cdcxhl.com

LINQ查詢的一點體會

當我們會熟練的使用以上的查詢方法對數(shù)據(jù)庫里的內(nèi)容做各種各樣的查詢以后，就應(yīng)當要了解這些數(shù)據(jù)庫操作的機制，及時調(diào)整各種數(shù)據(jù)操作語句，以較高的效率運行。那么，下面我們來看看LINQ的數(shù)據(jù)庫操作，看看她都做了些什么工作。

與NHibernate來比較，LINQ在O/R Mapping的性能與可控性上確實優(yōu)于NHibernate，首先，Linq默認的數(shù)據(jù)映射采用的是Attribute來實現(xiàn)，這是.NET特有的語法，在編譯時就已經(jīng)決定了數(shù)據(jù)對象的各種屬性，而NHibernate等大多數(shù)O/RMapping工具仍然采用XML映射文件來描述數(shù)據(jù)對象的屬性，從外部文件上讀取數(shù)據(jù)對象的屬性，顯然運行時效率要有所損失。其次,在獲得數(shù)據(jù)的方式上也有所差別，LINQ中強大的SQL分析機制，可以分析出各種數(shù)據(jù)操作的SQL語句，并且進行優(yōu)化，其效率的提升也是顯而易見的。

當然，作為一個O/R Mapping的工具來說，其效率一定達不到直接使用SQL語句訪問數(shù)據(jù)庫的效率，也就是我們通常所說的SqlDataReader/SqlDataAdapter訪問數(shù)據(jù)庫，但是，Linq的表現(xiàn)卻給了我們非常大的驚喜，我做了一個測試，使用SqlDataReader和LINQ做相同的大批量數(shù)據(jù)查詢時，落后竟然不到10%，而NHibernate的查詢效率，卻低了很多，幾乎慢了1倍。對于如此強大的數(shù)據(jù)映射功能，這樣的效率是我們可以接受的。但是很可惜的一點是，LINQ目前只能支持對SQLServer的支持（但可以支持XML、Entity等）。

在使用LINQ查詢進行數(shù)據(jù)查詢上，我們通過對LINQ生成的SQL語句進行分析，便可以優(yōu)化查詢，這是非常方便的，但是，針對數(shù)據(jù)更新的效率問題，我們不得不談?wù)凩INQ的數(shù)據(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ù)（這里為了簡便，我們僅僅取出***條，其實可以用Where取出滿足條件的記錄），然后把名字修改成“李四”，再更新到數(shù)據(jù)庫中。這段代碼，LINQ都干了些什么呢？通過查詢從數(shù)據(jù)庫中取出若干條記錄，放在內(nèi)存中，并且都標記為new（未改變）狀態(tài)，當修改了員工姓名的時候，被修改的對象被標記為Dirty(已改變),在SubmitChanges的時候，再為內(nèi)存中對象狀態(tài)為Dirty的記錄自動生成SQL語句并執(zhí)行，也就是說，我們要完成一次數(shù)據(jù)的更新，至少要完成一次查詢和一次更新。

LINQ查詢的一點分析：

由于采用了延時加載（Layze Load）的技術(shù)，在以上語句中實際從數(shù)據(jù)庫中取出的記錄只有1條，更新的時候也只更新這一條，因此效率仍然是非常高的，我在測試的過程中發(fā)現(xiàn)，從250000條數(shù)據(jù)中隨機抽取一條進行更新，實際的效率和從10條數(shù)據(jù)中隨機抽取一條進行更新幾乎沒有差別，因為比較更新狀態(tài)是在內(nèi)存中進行，因此效率是比較高的。下面我們再看看實際的更新生成了什么樣的SQL語句：

UPDATE [dbo].[Employee] SET [EmployeeName] =   @p4 WHERE ([EmployeeId] = @p0) AND ([DepId] = @p1) AND    ([EmployeeName] = @p2) AND ([EmployeeSalary] = @p3)

原來，我們只修改了EmployeeName的字段，生成的SQL語句卻也僅僅是更新了Employee字段。那么，我們再看看后面的條件，為什么會包含除了主鍵以外的其他條件呢？原來，這也是LINQ自動生成SQL語句的嚴謹所在，這是為了防止并發(fā)情況下，多個事務(wù)針對同一條記錄更新時發(fā)生錯誤，假如A事務(wù)更新了該記錄，則B事務(wù)更新會失敗。我們不禁要問，假如要更新主鍵字段怎么辦？會不會錯誤的更新到多條記錄呢？答案是肯定的，肯定會錯誤的更新到其他記錄，因此，LINQ中規(guī)定了主鍵字段是不允許更新的，如果確實要更新，那么就刪除掉該記錄，重新插入新紀錄。這么嚴謹?shù)腟QL語句，會給我們帶來一些麻煩，我們來看下面一個應(yīng)用場景：

如果我們在表中設(shè)有一個字段用于計數(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這個參數(shù)是計算好后傳入的，@p1這個參數(shù)是CountColumn原來的值。也就是說，CountColumn+1這個值不是由數(shù)據(jù)庫運算出來的，這樣一來，當并發(fā)數(shù)很高的時候，我們往往會更新失敗。我做了個測試，使用多線程模擬多用戶的情況下進行計數(shù)統(tǒng)計，數(shù)據(jù)庫中統(tǒng)計的值比使用靜態(tài)變量保存的值要小，這也就是說數(shù)據(jù)庫更新是存在失敗的情況。另外，這樣每次的更新，需要完成的操作有查找和更新兩個步驟，因此對于效率也有比較大的影響。

在這里，我們并不是要說明LINQ存在缺陷，因為這種情況可能在任何的O/R Mapping的框架下都得不到很好的解決，這里僅僅是想告訴我們，只有了解系統(tǒng)內(nèi)部運行的情況，才能設(shè)計出效率更高，更可靠的系統(tǒng)。

“LINQ查詢的效果舉例分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！