與SQL排序規則

影響性能我只是想看看下面幾件事：與SQL排序規則

Q1）Latin1_General_CI_AS不區分大小寫，區分重音：即SQL會看到下面的平等 - 「你好」和「HELLO」

使用LINQ我安靜經常這樣做：

db.Where(v => v.Email == "some email".ToLower())

Q2）假設我的理解到Q1是正確的，我只是在浪費處理時間打電話ToLower（）在我的查詢？

Q3）是否有人知道是否會有使用Latin1_General_bin在Latin1_General_CI_AS性能提升？即已經有已經在博客等進行性能測試（這種思想爲我寫的帖子，所以沒有找我自己還）

來源

2011-05-26 Stuart Blackler

整理並不僅僅影響它也會影響排序順序的查詢。永遠做你的查詢在這些列上使用'order by'？如果是這樣的話，你對這些語義有什麼語義？ – 2011-05-26 22:16:49

一般不是不。說實話，這取決於查詢的性質。我是否正確地說，案例/重音敏感度是影響排序順序的事情？ – 2011-05-26 22:26:05

'Latin1_General_bin'會將'A，B，a，b'（大寫第一）和'Latin1_General_CI_AS'排序爲'A，a，B，b'。我不記得排序規則如何影響排序的所有細節。 – 2011-05-26 22:40:32

一般SQL比較不區分大小寫。
但是也有例外，例如在MySQL中如果使用binary varchar比較將區分大小寫。

所以你ToLower將可能並不是完全是浪費時間。

的Latin1_General_bin是大小寫敏感的。
而Latin1_General_CI_AS不是。

區分大小寫的比較將在數據庫中更快，但你付出的價格，如果你想匹配「一些電子郵件」到「一些電子郵件」，你將不得不轉換爲小寫，失去所有的速度增益。
我還沒有計時，但我不認爲這是值得的麻煩。
我推薦在這個微優化之前巧妙地使用索引和查詢。

- 過早的優化是所有罪惡，高德納的根源。

來源

2011-05-26 22:17:43 Johan

實際性能： Table Adres包含320K行數據。當我們有電子郵件時，我們需要Adres.Id（如你的例子）。

數據庫（和表住址）排序規則是SQL_Latin1_General_CP1_CI_AS

爲了性能的優化，非聚集索引用柱電子郵件創建（包括Adres.Id列）

Queryies樣子：

SELECT Adres.ID,Email FROM csc.Adres WHERE EMAIL ='[email protected]' 

SELECT Adres.ID,Email FROM csc.Adres WHERE EMAIL='[email protected]' COLLATE Latin1_General_bin

1行返回的每個查詢

結果： enter image description here

似乎在第二種情況下，查詢不會被SQL Server識別爲SARG。爲什麼？讓我們看看細節。在第一種情況：

ScalarOperator ScalarString="CONVERT_IMPLICIT(nvarchar(4000),[@1],0)

而在第二：

ScalarOperator ScalarString="CONVERT_IMPLICIT(nvarchar(80),[CSCENTRUMTest].[csc].[Adres].[Email],0)=CONVERT_IMPLICIT(nvarchar(4000),CONVERT(varchar(8000),[@1],0),0)">

因此，在第二種情況下的電子郵件被轉化爲所需序列。這種情況不是SARG，而是執行索引掃描。

如果查詢不能被認定爲特別行政區政府（如LIKE '%some email%)」，計劃相同

假設：如果您的查詢可以識別像特區政府和你有適當的索引，沒有排序規則優先（它是不如做客戶端/服務端整理的談話）。

你可以在不同的性能調整的書/文章特別行政區政府信息。

來源

2011-05-27 06:34:04 Dalex

與SQL排序規則

回答

相關問題