top
Loading...
7.5.3.控制查詢優化器的性能
7.5.3. 控制查詢優化器的性能

查詢優化器的任務是發現執行SQL查詢的最佳方案。因為“”方案和“”方案之間的性能差別會巨大(也就是說,秒相對于小時或甚至天),大多數查詢優化器,包括MySQL的查詢優化器,總或多或少地在所有可能的查詢評估方案中搜索最佳方案。對于聯接查詢,MySQL優化器所調查的可能的方案數隨查詢中所引用的表的數目呈指數增長。對于小數量的表(典型小于7-10),這不是一個問題。然而,當提交的查詢更大時,查詢優化所花的時間會很容易地成為服務器性能的主要瓶頸。

查詢優化的一個更加靈活的方法是允許用戶控制優化器詳盡地搜索最佳查詢評估方案。一般思想是優化器調查的方案越少,它編譯一個查詢所花費的時間越少。另一方面,因為優化器跳過了一些方案,它可能錯過一個最佳方案。

優化器關于方案數量評估的行為可以通過兩個系統變量來控制:

·         optimizer_prune_level變量告訴優化器根據對每個表訪問的行數的估計跳過某些方案。我們的試驗顯示該類“有根據的猜測”很少錯過最佳方案,并且可以大大降低查詢編輯次數。這就是為什么默認情況該選項為on(optimizer_prune_level=1)。然而,如果你認為優化器錯過了一個更好的查詢方案,則該選項可以關閉(optimizer_prune_level=0),風險是查詢編輯花費的時間更長。請注意即使使用該啟發,優化器仍然可以探測呈指數數目的方案。

·         optimizer_search_depth變量告訴優化器對于每個未完成的“未來的”方案,應查看多深,以評估是否應對它進一步擴大。optimizer_search_depth值較小會使查詢編輯次數大大減小。例如,如果optimizer_search_depth接近于查詢中表的數量,對1213或更多表的查詢很可能需要幾小時甚至幾天的時間來編譯。同時,如果用optimizer_search_depth等于34編輯,對于同一個查詢,編譯器編譯時間可以少于1分鐘。如果不能確定合理的optimizer_search_depth值,該變量可以設置為0,告訴優化器自動確定該值。

作者:mysql.com
來源:http://dev.mysql.com/doc/refman/5.1/zh/optimization.html
北斗有巢氏 有巢氏北斗