LINQ to SQL-當心CHAR(1)欄位比對條件寫法的效能差異

今天意外發現,LINQ to SQL在轉譯CHAR(1)欄位比對時,可能因寫法不同而產生極無效率的SQL指令!

當資料表的欄位為CHAR(1)時,在DataContext裡產生的對應物件型別是char,而我們直覺上可能寫成CharCol == 'A'的比對條件。但今天發現一件可怕的事...

CharCol == 'A'的寫法會被轉換成極無效率的WHERE UNICODE(CharCol) = 65

對SQL查詢效能略有研究的人都知道,Func(SomeCol) = SomeValue的寫法會迫使SQL Server把每一列的資料都挖出來運算後再比對,無法善用Index做有效率的搜索。用這種寫法的好處是可以居分大小寫不同,但效能代價十分可觀。網路上找到文章做過實測,效能差了三倍! 該文建議解法是手動將資料物件的char型別改為string,不過這涉及更動自動產生的程式碼,一旦更新DBML就得重調。我則找到另一種替代解法--改用CharCol.Equals('A')!

使用LINQPad來驗證: [關於LINQPad可參考demo的介紹文]

由以上測試可知p.Enabled.Equals('Y')會被轉換成Enabled = 'Y',就不會導致前述的查詢效能問題。

【結論】

LINQ to SQL在欄位為CHAR(1)時,若要做不分大小寫的比對,請用.Equals()取代==,以免產生效能低落的T-SQL查詢語法。

【同場加映】

System.Data.Linq.SqlClient.SqlMethods.Like(p.Player, "Dark%")可以直接對映出LIKE T-SQL語法!

歡迎推文分享:
Published 25 March 2010 09:00 PM 由 Jeffrey
Filed under: , ,
Views: 10,228



意見

沒有意見

你的看法呢?

(必要的) 
(必要的) 
(選擇性的)
(必要的) 
(提醒: 因快取機制,您的留言幾分鐘後才會顯示在網站,請耐心稍候)

5 + 3 =

搜尋

Go

<March 2010>
SunMonTueWedThuFriSat
28123456
78910111213
14151617181920
21222324252627
28293031123
45678910
 
RSS
創用 CC 授權條款
【廣告】
twMVC

Tags 分類檢視
關於作者

一個醉心技術又酷愛分享的Coding魔人,十年的IT職場生涯,寫過系統、管過專案, 也帶過團隊,最後還是無怨無悔地選擇了技術鑽研這條路,近年來則以做一個"有為的中年人"自許。

文章典藏
其他功能

這個部落格


Syndication