有時候一個念頭或想法在不經意間蹦出——就像是一段美好的邂逅，讓人淡然而有些欣喜。寫這篇博客的由來也是如此，——“查詢條件的排序的不同可能會對查詢效率有影響”的想法突然出現在我的腦海里，而且我饒有興致的細想了下，經過測試，但無奈的是我本地只有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看起來一樣，最后查詢到的結果也相同，只是查詢條件價格和分類的順序不同。以
如果我以上的設想或考慮成立，我倒是感覺為了提高查詢效率，應該在每個項目的后台管理中可以動態根據不同時期或情況設置數據查詢各個條件的排序。
此文就寫到這里，提出兩個問題，希望知道的朋友能不吝賜教！
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語句，並對其進行優化處理！