以淘寶商品搜索漫談查詢條件的排序對效率的影響(SQL查詢性能優化,附調優(性能診斷)DMV)

 　　有時候一個念頭或想法在不經意間蹦出——就像是一段美好的邂逅，讓人淡然而有些欣喜。寫這篇博客的由來也是如此，——“查詢條件的排序的不同可能會對查詢效率有影響”的想法突然出現在我的腦海裏，而且我饒有興致的細想了下，經過測試，但無奈的是我本地只有2w多的數據量，數據量太小，無法測試出其真實的結果，這也是爲何這篇博客的標題中說是'漫談'的原因;'漫談'很可能就是亂彈，我所說的只是我想當然的，未經證實；但我仍想也感覺有必要把所考慮的跟大家分享交流下，就是板兒磚滿天飛也無所謂，以求正解！

　　

　　  如上圖，就是淘寶網的商品搜索頁，我所要說的會直截了當的圍繞上圖談起——只用看上圖中綠色框部分，對於搜索功能的sql查詢，分別是 價格和分類 這兩個查詢(where)條件，單就(where)條件的拼接有以下兩種寫法（以下sql只是爲了輔助說明我的想法而已，非淘寶真實實現）：

　　  1.select * from product where price>=45 and price<=138 and category='恆源祥'

　　  2.select * from product where category='恆源祥' and price>=45 and price<=138

　　  兩條sql看起來一樣，最後查詢到的結果也相同，只是查詢條件價格和分類的順序不同。以SQL Server爲例，我不清楚數據庫sql查詢分析引擎是否會對查詢sql語句進行優化或其它處理——排除這點，我認爲第二條sql的執行效率會更高、查詢速度會更快，理由是：在淘寶網海量的商品數據中進行上面的搜索查詢，如果sql語句是(查詢條件)分段處理的話，第一條sql的第一個條件(price>=45 and price<=138)肯定要比第二條sql的第一個條件(category='恆源祥')返回的數據要多，因爲基本上每種分類中都可能存在(price>=45 and price<=138)的商品信息，這樣從第一個條件返回的結果中進行第二個條件的篩選——相當於是分別從1000w和10w記錄數的兩個表中進行數據查詢，數據量少的相對而言查詢速度會更快，於是，第二條sql的整體查詢速度會更快。

　　 如果我以上的設想或考慮成立，我倒是感覺爲了提高查詢效率，應該在每個項目的後臺管理中可以動態根據不同時期或情況設置數據查詢各個條件的排序。

　　 此文就寫到這裏，提出兩個問題，希望知道的朋友能不吝賜教！

       Q1：數據庫sql查詢分析引擎是否會對查詢sql語句進行優化或其它處理？

　　 Q2：本文所說的觀點是否正確？

　　 最後，附上SQL Server調優(性能診斷)DMV查詢SQL，希望對需要的朋友有所幫助。

 1 set transaction isolation level read uncommitted   2    3 select top 20   4 CAST(qs.total_elapsed_time/1000000.0 as decimal(28,2))   5 as [Total Elapsed Duration (s)]   6 ,qs.execution_count   7 ,SUBSTRING(qt.text,(qs.statement_start_offset/2)+1,   8 ((Case when qs.statement_end_offset=-1   9 Then len(CONVERT(Nvarchar(max),qt.text))*2  10 else  11 qs.statement_end_offset  12 end - qs.statement_start_offset)/2)+1) as [Individual Query]  13 ,qt.text as [Parent Query]  14 ,DB_NAME(qt.dbid) as databseName  15 ,qp.query_plan  16 from sys.dm_exec_query_stats qs  17 cross apply sys.dm_exec_sql_text(qs.sql_handle) qt  18 cross apply sys.dm_exec_query_plan(qs.plan_handle) qp  19   20 order by total_elapsed_time desc

　　查詢結果如下：

　　

      通過以上查詢可以得到最消耗性能的前20條SQL語句，並對其進行優化處理！