|
|
| 表定義 | 生成的實(shí)體 |
2.
如果要查詢LineCode=='A'的記錄,可以這樣定義Linq查詢語句
| var test1 = from p in db.ProductLines |
| where p.LineCode =='A' |
| select p; |
生成的SQL語句是這樣的
| SELECT [t0].[LineCode], [t0].[LineName], [t0].[JPH], [t0].[QueueCount] |
| FROM [dbo].[ProductLine] AS [t0] |
| WHERE UNICODE([t0].[LineCode]) = @p0 |
| -- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [65] |
| -- Context: SqlProvider(Sql2000) Model: AttributedMetaModel Build: 3.5.21022.8 |
注意到Where語句了嗎?是WHERE UNICODE([t0].[LineCode]) = 65,這里先取LineCode列內(nèi)容的UNICODE再和'A'的UNICODE比較。我們知道'A'和'a'的UNICODE是不同的。UNICODE('A') =65,UNICODE('a')=97,也就是說,我們?cè)贚inq to SQL中這二個(gè)查詢的結(jié)果是不一樣的。
| Linq 語句 |
|
| ||||||||
| 生成SQL語句 |
|
|
明顯,在Linq to sql是查詢char(1)類型字段是區(qū)分大小寫的。
這還會(huì)導(dǎo)致一個(gè)比較嚴(yán)重的問題,我們知道在SQL Server中,任何在運(yùn)算符左邊的操作都會(huì)使SQL采用全表掃描。也就是說,Linq的這個(gè)查詢,會(huì)引起全表掃描,即使[LineCode]列上定義了聚合索引。而如果是where [linecode]='A',則可以使用索引。我們看下這二種情況時(shí)的查詢執(zhí)行計(jì)劃對(duì)比。
圖中可以看出,Linq to SQL 生成的SQL語句是表掃描,而后者則是索引查找。
3.
對(duì)策
在DBML設(shè)計(jì)器中將LineCode改成string類型。
看一下改了之后的查詢
|
| |||||||||
| Linq | sql |
改為string后,生成的SQL不再用UNICODE函數(shù)了,就解決了區(qū)分大小寫和引起全表掃描的問題。但又引起一個(gè)新的問題,因?yàn)閿?shù)據(jù)庫中存儲(chǔ)的數(shù)據(jù)長度是1,在Insert和Update時(shí)就要注意,LineCode不要輸入過長的內(nèi)容,否則會(huì)出錯(cuò)了。
標(biāo)簽:福建 商洛 泉州 美容院 珠海 天水 呼和浩特 西寧
巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《LINQ to SQL:處理char(1)字段的方式會(huì)引起全表掃描問題》,本文關(guān)鍵詞 LINQ,SQL,處理,char,字段,的,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。