深度看點 Linq查詢與性能解析
眾人對LINQ查詢持有不同的態(tài)度，有的說容易實現(xiàn)，有的說難操作，那到底是什么樣子呢，筆者特地為此做了一個Linq查詢與性能分析，請看下文吧。
Orcas（VS2008&Framework3.5）給我們帶來了很多令人興奮的新特性，尤其是LINQ的引進(jìn)，可以說方便了一大批開發(fā)人員和框架設(shè)計人員。過去，當(dāng)我們使用O/RMapping的一些框架時，最擔(dān)心的應(yīng)該是復(fù)雜的查詢和數(shù)據(jù)庫操作的性能問題，那么LINQ在這個方面給我們帶來了什么呢？從LINQ查詢開始說起吧。
一：LINQ查詢：
一個項目中，對數(shù)據(jù)庫操作最多的應(yīng)該就是查詢，特別是復(fù)雜一些的項目，查詢往往是從很多張表里取一些數(shù)據(jù)，“東拼西湊”的呈現(xiàn)給用戶。如果不使用O/R Mapping呢，我們處理的方式無非是兩種：復(fù)雜的SQL語句或者是存儲過程。
但是，在使用了O/R Mapping的情況下，為了保證取出的數(shù)據(jù)是強(qiáng)類型，不得不用多個方法來進(jìn)行拼湊，麻煩且不說，性能損失是肯定的，那么也就出現(xiàn)了O/R Mapping框架和未封裝的ADO.NET一起用的尷尬場面。那么LINQ查詢怎么處理的呢？首先我們先來看一些復(fù)雜的查詢語法。
設(shè)計兩張表，分別為表示部門（Department）和員工（Employee）：
1、 模糊查詢：
模糊查詢在O/RMapping的框架中是比較難實現(xiàn)的，即使實現(xiàn)，效率也不是很高，LINQ提供了我們豐富的模糊查詢的方法，比如我們要在Employee表中查姓張的人，可以這樣：
- DBDataClassesDataContext dbdata = new DBDataClassesDataContext();
- var query = from employee in dbdata.Employees where
- employee.EmployeeName.StartsWith("張") select employee;
在實際執(zhí)行的時候，這句話被轉(zhuǎn)換成了：
- SELECT [t0].[EmployeeId], [t0].[DepId], [t0].[EmployeeName],
- [t0].[EmployeeSalary] FROM [dbo].[Employee] AS
- [t0] WHERE [t0].[EmployeeName] LIKE @p0
這樣的SQL語句，這個里面的@p0這個參數(shù)在執(zhí)行的時候加上了“%”，也就是以@p0開頭的任何符合條件的記錄都被取出來了。這樣的方法在LINQ查詢中還有Contains、EndsWith等。
2、嵌套查詢：
如果我們需要取出市場部的所有員工，在以往的O/R Mapping框架中，往往需要取兩次（我們不考慮存在映射關(guān)系的情況），一次是取出市場部的編號，再使用編號來取出所有員工。LINQ查詢給我們提供了更好的解決辦法，我們可以這樣操作：
- var query = from employee in dbdata.Employees where employee.DepId ==
- (from department in dbdata.Departments where department.DepName == "市場部"
- select department ).Single().DepId
- select employee;
這里我們使用了嵌套查詢來完成，這句話在執(zhí)行的時候，被轉(zhuǎn)換成了SQL的嵌套查詢：
- SELECT [t0].[EmployeeId], [t0].[DepId], [t0].[EmployeeName],
- [t0].[EmployeeSalary] FROM [dbo].[Employee] AS [t0] WHERE [t0].[DepId] =
- (SELECT [t1].[DepId] FROM [dbo].[Department] AS
- [t1] WHERE [t1].[DepName] = @p0)
當(dāng)然，在這里，我們不必那么麻煩，只需要使用已經(jīng)存在的實體關(guān)系，就可以輕松的完成：
- var query = from employee in dbdata.Employees where
- employee.Department.DepName == "市場部"
- select employee;
不過，這和剛才的查詢卻有本質(zhì)的差別，我們來看看這里，LINQ查詢轉(zhuǎn)換成什么樣的SQL語句了：
- SELECT [t0].[EmployeeId], [t0].[DepId], [t0].[EmployeeName],
- [t0].[EmployeeSalary] FROM [dbo].[Employee] AS
- [t0] LEFT OUTER JOIN [dbo].[Department] AS [t1] ON [t1].[DepId] =
- [t0].[DepId] WHERE [t1].[DepName] = @p0
這里，轉(zhuǎn)換出來的并不是嵌套的SQL語句，而被轉(zhuǎn)換成了左連接查詢，可以看出，嵌套查詢是我們在特殊的情況下，可以使用的一個利器。
3、投影
如果說剛才的查詢，還只是很簡單的查詢，那么結(jié)合匿名類來實現(xiàn)投影查詢，則是LINQ查詢提供的一個利器，這種方法非常靈活，同時也滿足了我們絕大部分的查詢需求。下面我們來看一個例子：我們需要查詢出部門工資的總和，怎么做呢？
- var query = from department in dbdata.Departments
- select new{ depid = department.DepId, depname=department.DepName,
- depsalary =
- department.Employees.Sum(e => e.EmployeeSalary) };
這句查詢語句中，在new關(guān)鍵字后面生成了一個匿名類，這個類有三個屬性，分別是 depid，depname和depsalary，其中，depsalary是經(jīng)過計算獲得，這句話被轉(zhuǎn)換成：
- SELECT [t0].[DepId] AS [depid], [t0].[DepName] AS [depname],
- (SELECT SUM([t1].[EmployeeSalary]) FROM [dbo].[Employee] AS [t1]
- WHERE [t1].[DepId] =
- [t0].[DepId] ) AS [depsalay] FROM [dbo].[Department] AS [t0]
好優(yōu)雅的代碼，實在是太方便了。
4、使用LINQ查詢的擴(kuò)展方法
LINQ查詢提供了很多擴(kuò)展方法，方便我們做各種查詢，我們來看幾個典型的擴(kuò)展方法:
a) Average、Max
- Decimal x = dbdata.Employees.Average(e => e.EmployeeSalary);
- Decimal y = dbdata.Employees.Max(e => e.EmployeeSalary);
這是計算出員工的平均工資與***工資，你不需要編寫任何的SQL語句，Orcas中提供的LINQ到SQL對象關(guān)系映射器會處理獲取，跟蹤，和更新映射到你的數(shù)據(jù)庫數(shù)據(jù)定義和存儲過程的對象。
你只要使用任何LINQ查詢擴(kuò)展方法對結(jié)果進(jìn)行過濾和構(gòu)形即可，LINQ到SQL會執(zhí)行獲取數(shù)據(jù)所需的SQL代碼(注意，上面的 Average和Max 擴(kuò)展方法很明顯地不會從數(shù)據(jù)表中返回所有的數(shù)據(jù)行，它們會使用TSQL的聚合函數(shù)來計算數(shù)據(jù)庫中的值，然后只返回一個標(biāo)量值)。
b) Where、OrderBy
有時候，我們只對某張表做簡單的查詢和排序，那么，這個時候不必寫冗長的LINQ查詢語句，直接使用LINQ擴(kuò)展方法即可，如：
- var query = dbdata.Employees.Where(e => e.EmployeeSalary > 2000).
- OrderBy(e => e.EmployeeName);
這里使用了Lambda語法，這句話被轉(zhuǎn)換成以下的SQL語句：
- SELECT [t0].[EmployeeId], [t0].[DepId], [t0].[EmployeeName],
- [t0].[EmployeeSalary] FROM [dbo].[Employee] AS [t0] WHERE
- [t0].[EmployeeSalary] > @p0 ORDER BY [t0].[EmployeeName]
以上是通過利用由Lambda提供的對表達(dá)式樹支持，以及IQueryable
C）Take、Skip
對于大批量的數(shù)據(jù)處理，一直是開發(fā)人員的比較頭疼的事情，微軟在.NET1.1到2.0中的Gridview等控件，對大批量數(shù)據(jù)的處理上一直都不是很理想，LINQ查詢對于大批量數(shù)據(jù)的處理，可以很好的解決這個方面的問題。
- var query = dbdata.Employees.Skip(10).Take(10);
這句話表示跳過該表的10條記錄，再取10條，也就是取第11至20條記錄，轉(zhuǎn)換成SQL語句如下：
- SELECT [t1].[EmployeeId], [t1].[DepId], [t1].[EmployeeName],
- [t1].[EmployeeSalary] FROM
- (SELECT ROW_NUMBER() OVER (ORDER BY [t0].[EmployeeId],
- [t0].[DepId], [t0].[EmployeeName], [t0].[EmployeeSalary]) AS
- [ROW_NUMBER], [t0].[EmployeeId],
- [t0].[DepId], [t0].[EmployeeName],
- [t0].[EmployeeSalary] FROM [dbo].[Employee] AS [t0]) AS
- [t1] WHERE [t1].[ROW_NUMBER] BETWEEN
- @p0 + 1 AND @p0 + @p1 ORDER BY [t1].[ROW_NUMBER]
從以上這句SQL語句來看，最消耗性能分頁操作完全交給了數(shù)據(jù)庫操作，其處理的機(jī)制不再像Gridview控件的分頁，是將數(shù)據(jù)全部取出，然后再進(jìn)行分頁顯示，因此效率上要高了很多。
D）ToList和ToArray
在默認(rèn)情況下，查詢結(jié)果的數(shù)據(jù)類型是IEnumerable
在這里，我們需要知道的是：使用查詢語句查詢結(jié)果的時候，實際上并沒有真正操作數(shù)據(jù)庫，這里是運用的延遲加載的機(jī)制，如果不希望使用延遲加載，而是需要立刻知道查詢的結(jié)果時，使用ToList或者是ToArray便可以做到。這是非常有用的機(jī)制。
比如我們需要顯示兩個部門的員工時，部門可以先取出放置在List中，然后再依次取出各個部門的員工，這時訪問的效率要高一些，因為不需要每次都訪問數(shù)據(jù)庫去取出部門。
二：數(shù)據(jù)操作的性能分析
當(dāng)我們會熟練的使用以上的查詢方法對數(shù)據(jù)庫里的內(nèi)容做各種各樣的查詢以后，就應(yīng)當(dāng)要了解這些數(shù)據(jù)庫操作的機(jī)制，及時調(diào)整各種數(shù)據(jù)操作語句，以較高的效率運行。那么，下面我們來看看LINQ的數(shù)據(jù)庫操作，看看她都做了些什么工作。
與NHibernate來比較，LINQ在O/R Mapping的性能與可控性上確實優(yōu)于NHibernate，首先，Linq默認(rèn)的數(shù)據(jù)映射采用的是Attribute來實現(xiàn)，這是.NET特有的語法，在編譯時就已經(jīng)決定了數(shù)據(jù)對象的各種屬性，而NHibernate等大多數(shù)O/RMapping工具仍然采用XML映射文件來描述數(shù)據(jù)對象的屬性，從外部文件上讀取數(shù)據(jù)對象的屬性，顯然運行時效率要有所損失。
其次,在獲得數(shù)據(jù)的方式上也有所差別，LINQ中強(qiáng)大的SQL分析機(jī)制，可以分析出各種數(shù)據(jù)操作的SQL語句，并且進(jìn)行優(yōu)化，其效率的提升也是顯而易見的。
當(dāng)然，作為一個O/R Mapping的工具來說，其效率一定達(dá)不到直接使用SQL語句訪問數(shù)據(jù)庫的效率，也就是我們通常所說的SqlDataReader/SqlDataAdapter訪問數(shù)據(jù)庫，但是，Linq的表現(xiàn)卻給了我們非常大的驚喜。
我做了一個測試，使用SqlDataReader和LINQ做相同的大批量數(shù)據(jù)查詢時，落后竟然不到10%，而NHibernate的查詢效率，卻低了很多，幾乎慢了1倍。對于如此強(qiáng)大的數(shù)據(jù)映射功能，這樣的效率是我們可以接受的。但是很可惜的一點是，LINQ查詢目前只能支持對SQLServer的支持（但可以支持XML、Entity等）。
在數(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ù)（這里為了簡便，我們僅僅取出***條，其實可以用Where取出滿足條件的記錄），然后把名字修改成“李四”，再更新到數(shù)據(jù)庫中。
這段代碼，LINQ查詢都干了些什么呢？通過查詢從數(shù)據(jù)庫中取出若干條記錄，放在內(nèi)存中，并且都標(biāo)記為new（未改變）狀態(tài)，當(dāng)修改了員工姓名的時候，被修改的對象被標(biāo)記為Dirty(已改變)。
在SubmitChanges的時候，再為內(nèi)存中對象狀態(tài)為Dirty的記錄自動生成SQL語句并執(zhí)行，也就是說，我們要完成一次數(shù)據(jù)的更新，至少要完成一次查詢和一次更新。
由于采用了延時加載（Layze Load）的技術(shù)，在以上語句中實際從數(shù)據(jù)庫中取出的記錄只有1條，更新的時候也只更新這一條，因此效率仍然是非常高的，我在測試的過程中發(fā)現(xiàn)，從250000條數(shù)據(jù)中隨機(jī)抽取一條進(jìn)行更新，實際的效率和從10條數(shù)據(jù)中隨機(jī)抽取一條進(jìn)行更新幾乎沒有差別，因為比較更新狀態(tài)是在內(nèi)存中進(jìn)行，因此效率是比較高的。下面我們再看看實際的更新生成了什么樣的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ā)情況下，多個事務(wù)針對同一條記錄更新時發(fā)生錯誤，假如A事務(wù)更新了該記錄，則B事務(wù)更新會失敗。
我們不禁要問，假如要更新主鍵字段怎么辦？會不會錯誤的更新到多條記錄呢？答案是肯定的，肯定會錯誤的更新到其他記錄，因此，LINQ中規(guī)定了主鍵字段是不允許更新的，如果確實要更新，那么就刪除掉該記錄，重新插入新紀(jì)錄。這么嚴(yán)謹(jǐn)?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ù)庫運算出來的，這樣一來，當(dāng)并發(fā)數(shù)很高的時候，我們往往會更新失敗。我做了個測試，使用多線程模擬多用戶的情況下進(jìn)行計數(shù)統(tǒng)計，數(shù)據(jù)庫中統(tǒng)計的值比使用靜態(tài)變量保存的值要小，這也就是說數(shù)據(jù)庫更新是存在失敗的情況。
另外，這樣每次的更新，需要完成的操作有查找和更新兩個步驟，因此對于效率也有比較大的影響。
以上就是對LINQ查詢與性能的分析。
【編輯推薦】
