在 實際的工作中,尤其是在生產環境裡邊,SQL語句的優化問題十分的重要,它對數據庫的性能的提升也起著顯著的作用.我們總是在抱怨機器的性能問題,總是在 抱怨並發訪問所帶來的瑣問題,但是如果我們對沒一條SQL語句進行優化,盡管不能說可以解決全部問題,但是至少可以解決大部分問題.
1.Top排序問題.
我們經常要對表某個字段進行排序,然後取前N名.所以我們會寫如下的SQL語句:
如 果表非常大的話,那麼這樣的操作是非常消耗資源的,因為SQL Server要對整個表進行排序,然後取前N條記錄.這樣的造作是在Temdb裡邊進行的,所以極端的時候會報Log已滿這樣的錯誤.為了避免進行全表的 排序,我們要做的僅僅是在Score上建立索引,這樣因為Score索引的葉級是有序的,只要在Score所以的頁級取前100個,然後根據書簽查找到實 際的記錄,這樣對DB的性能就會有極大的提升.
2.同一天問題.
我們經常要查找和一個日期同一天的記錄,所以我們回寫如下的SQL語句;
但是這樣寫的SQL語句帶來的問題就是不能使用F_Time上的索引了.為了近可能的使用F_Time上的索引,我們可以使用時間段查詢的方式來代替上邊的語句.
這樣就解決了使用不上索引的問題.
3.利用索引進行分組操作.
我們經常要對某一字段進行分組,而對另外一些字段進行聚合操作.如果我們對分組的字段合理的使用索引,可以加快我們分組的速度.下邊以Northwind的Orders表為例:
-- orders表的EmployeeID上建有索引.
-- 查看執行計劃,此查詢利用了EmployeeID上的索引.如改成如下查詢:
-- 查看執行計劃,此查詢則沒有使用EmployeeID上的索引.而是使用了全表掃描.那麼原因是什麼呢?是因為Freight沒有在EmployeeID 的索引上,所以通過索引不能得到結果.而如果通過書簽查詢的成本太高,所以SQL Server選擇了使用全表掃描.而如果我們執行在EmployeeID和Freight上建立復合索引呢?
-- 再次執行第二個查詢.查看執行計劃.SQL Server使用的我們建立的索引.只需要使用索引就可以查詢到結果,極大的提高了我們的查詢速度.