對於高效能資料庫操作，只靠設計最優的庫表結構、建立最好的索引是不夠的，還需要合理的設計查詢。如果查詢寫得很糟糕，即使庫表結構再合理、索引再合適，也無法實現高效能。查詢優化、索引優化、庫表結構優化需要齊頭並進，一個不落。

6.1 為什麼查詢速度會慢

通常來說，查詢的生命週期大致可以按照順序來看：從客戶端>>伺服器>>在伺服器上進行解析>>生成執行計劃>>執行>>返回結果給客戶端。其中執行可以認為是整個生命週期中最重要的階段，這其中包括了大量為了檢索資料到儲存引擎的呼叫以及呼叫後的資料處理，包括排序、分組等。瞭解查詢的生命週期、清楚查詢的時間消耗情況對於優化查詢有很大的意義。

6.2 優化資料訪問

查詢效能低下的最基本的原因是訪問的資料太多。大部分效能低下的查詢都可以通過減少訪問的資料量的方式進行優化。

1.確認應用程式是否在檢索大量超過需要的資料。這通常意味著訪問了太多的行，但有時候也可能是訪問了太多的列。

2.確認MySQL伺服器層是否在分析大量超過需要的資料行。

6.2.1 是否向資料庫請求了不需要的資料

請求多餘的資料會給MySQL伺服器帶來額外的負擔，並增加網路開銷，另外也會消耗應用伺服器的CPU記憶體和資源。這裡有一些典型案例：

1、查詢不需要的記錄：例如在新聞網站中取出100條記錄，但是隻是在頁面上顯示10條。實際上MySQL會查詢出全部的結果，客戶端的應用程式會接收全部的結果集資料，然後拋棄其中大部分資料。最簡單有效的解決方法就是在這樣的查詢後面加上LIMIT。

2、多表關聯時返回全部列，例如：

3、總是取出全部的列：每次看到SELECT *的時候都需要懷疑是不是真的需要返回全部的列？取出全部列，會主優化器無法完成索引覆蓋掃描這類優化，還會為伺服器帶來額外的IO、記憶體和CPU的消耗。如果應用程式使用了某種快取機制，或者有其他考慮，獲取超過需要的資料也可能有其好處，但不要忘記這樣做的代價是什麼。獲取並快取所有的列的查詢，相比多個獨立的只獲取部分列的查詢可能就更有好處。

4、重複查詢相同的資料：不要不斷地重複執行相同的查詢，然後每次都返回完全相同的資料。當初次查詢的時候將這個資料快取起來，需要的時候從快取中取出，這樣效能顯然更好。

6.2.2 MySQL是否在掃描額外的記錄

對於MySQL，最簡單的衡量查詢開銷的三個指標有：響應時間、掃描的行數、返回的行數。這三個指標都會記錄到MySQL的慢日誌中，所以檢查慢日誌記錄是找出掃描行數過多的查詢的好辦法。

響應時間

響應時間是兩個部分之和：服務時間和排隊時間，一般常見和重要的等待是IO和鎖等待。

掃描的行數和返回的行數

分析查詢時，檢視該查詢掃描的行數是非常有幫助的。一定程度上能夠說明該查詢找到需要的資料的效率高不高。理想的情況下掃描的行數和返回的行數應該是相同的。當然這只是理想情況。一般來說掃描的行數對返回的行數的比率通常很小，一般在1：1到10：1之間。

掃描的行數和訪問型別

MySQL有好幾種訪問方式可以查詢並返回一行結果。有些訪問方式可能需要掃描很多行才能返回一行結果，也有些訪問方式可能無須掃描就能返回結果。

在EXPLAIN語句的TYPE列返回了訪問型別。如果查詢沒有辦法找到合適的訪問型別，那麼解決的最好辦法通常就是增加一個合適的索引。索引讓MySQL以最高效、掃描行最少的方式找到需要的記錄。

一般MySQL能夠使用如下三種方式應用WHERE條件，從好到壞依次為：

1、在索引中使用WHERE條件來過濾不匹配的記錄。這是在儲存引擎層完成的。

2、使用索引覆蓋掃描（在extra列中出現了using index）來返回記錄，直接從索引中過濾不需要的記錄並返回命中的結果。這是在MySQL伺服器層完成的，但無須回表查詢記錄。

3、從資料表中返回資料，然後過濾不滿足條件的記錄（在extra列中出現using where）。這在MySQL伺服器層完成，MySQL需要先從資料表讀出記錄然後過濾。

6.3 重構查詢的方式

6.3.1 一個複雜查詢還是多個簡單查詢

MySQL內部每秒能夠掃描記憶體中上百萬行資料，相比之下，MySQL響應資料給客戶端就慢得多了。在其他條件都相同的時候，使用盡可能少的查詢當然是更好的。但是有時候，將一個大查詢分解為多個小查詢也是很有必要的。

6.3.2 切分查詢

有時候對於一個大查詢我們需要“分而治之”，對於刪除舊資料，如果用一個大的語句一次性完成的話，則可能需要一次性鎖住很多資料、佔滿整個事務日誌、耗盡系統資源、阻塞很多小的但重要的查詢。將一個大的DELETE語句切分成多個較小的查詢可以儘可能小地影響MySQL效能，同時還可以減少MySQL複製的延遲。例如我們需要每個月執行一次下面的查詢：

那麼可以用類似下面的辦法來完成同樣的工作：

相關推薦