什么時候 MySQL 查詢會變慢？
前面幾篇文章和小伙伴們聊的基本上都是從索引的角度去優化 MySQL 查詢，然而，索引創建的好，并不意味著查詢就一定快，影響查詢效率的因素特別多，今天我們就來聊一聊這些可能影響到查詢的因素。
1. 查詢流程
開始今天的內容之前，先來和小伙伴們大概捋一捋 MySQL 的查詢流程。我們來看如下一張圖：
- 首先，用戶通過連接器和服務端之間建立通信連接，這個說白了就是一個 Socket 通信，用戶名/密碼的校驗，用戶權限的判斷等等，都是在這個連接器中完成的。
- 接下來需要對我么傳入的 SQL 進行解析，這塊跟代碼的執行流程其實差不多，先做詞法分析，識別出各種關鍵字，然后再做語法分析，語法分析就是根據 MySQL 的各種語法規則，去判斷 SQL 是否滿足語法規則。
- 接下來就是查詢優化器出場，查詢優化器就是分析要執行的 SQL，判斷應該選擇哪一個索引，包括在多表聯合查詢的時候，各個表的連接順序也是由查詢優化器來決定的，優化器執行完畢之后，會生成查詢執行計劃，我們平時通過 explain 關鍵字查看到的就是這個。
- 最后就是執行器了，執行器調用搜索引擎提供的具體接口去獲取數據。
這張圖大家大概有個印象，在后續的 MySQL 查詢和優化中，很多東西就容易理解了。
接下來我們就來看看什么情況下查詢會變慢。
2. 查詢了不需要的記錄
數據按需取用。有時候我們會忽略多拿數據對查詢性能的影響，然而優化是一個錙銖必較的事情，需要多少數據就查詢多少，要盡量避免數據庫查詢 100 條，結果前端只展示 10 條這種情況。如有需要，可以通過 limit 來限制數據庫查詢出來的數據總量。
如果在查詢的時候使用了唯一性索引的話，那么查詢到記錄之后 MySQL 就停止掃描了；但是如果查詢的時候使用的是非唯一性索引的話，那么掃描到第一條記錄之后，還會繼續向后掃描，直到掃描到第一條不滿足條件的記錄為止，對于這種情況，如果我們確定查詢的結果只有一條，則可以通過 limit 進行限制，設置 limit 1，那么掃描到第一條滿足條件的記錄之后，就不會繼續掃描了。
3. 返回需要的列
查詢的時候盡量避免 select *，這個問題在之前的文章中松哥其實和大家聊過了，因為很多時候我們在前端其實并不需要使用到那么多字段，可能只是為了查詢簡單，直接來一個 select *，有時候列數和數據總量都比較少的時候，這么寫也看不出來性能明顯的差異，但是當列數和數據量大了，那么 select * 帶來的影響就會比較大了。
特別是有的時候多表聯合查詢，如果用 select * 就會把多張表的查詢結果拼接到一起，那么此時查詢結果的列數就會成倍增加。
在前面的文章中，松哥也和大家提到過覆蓋索引，如果索引設計得當，那么在查詢的時候可以通過覆蓋索引來提高查詢的性能，但是如果使用了 select * 那么大概率是用不了覆蓋索引了。
4. 恰到好處的緩存
這里舉一個 TienChin 項目的例子，用戶登錄成功之后，在后續的流程中，經常會用到當前登錄用戶的信息，如果每次都去數據庫查詢，每次查詢返回結果都是一致的，沒有必要，此時我們可以將用戶信息存入到 Redis 緩存中，需要的時候從 Redis 中提取就可以了。
在項目中，對于這些需要多次頻繁查詢，且每次查詢返回結果一樣的數據，都可以選擇將之存入到緩存中以提高查詢性能。
5. 關注掃描行數
在查詢的時候，我們可以通過 explain 來查看執行計劃，執行計劃中有一個指標是掃描行數，如下圖中的 rows，這個就表示查詢優化器預估要掃描多少行記錄，filtered 則表示預估滿足條件的比例。
一般在單表查詢時候我們并不會特別關注 filtered 字段，在多表聯合查詢的時候會比較關注該字段的值。
6. 關注掃描類型
這一條實際上就是讓大家關注前面查詢計劃中的 type 字段的值，type 字段的取值有很多種，例如常見的 index、ALL、range、const 以及 ref，還有一些不常見的如 system、eq_ref、fulltext、ref_or_null、index_merge、unique_subquery、index_subquery 等，每一種都代表了不同的查詢計劃，再結合查詢計劃中的 Extra 字段中的值，我們大致上可以將查詢分為三種類型：
- 直接調用存儲引擎層進行查詢，查詢結果在 MySQL Server 層不需要額外處理，直接返回給客戶端即可。
- 直接從索引中過濾出來想要的值并返回給客戶端，這種時候，過濾雖然發生在 MySQL Server 層，但是由于不需要回表，效率也還過得去。
- 從數據表中查詢到相應的記錄，然后在 MySQL Server 層進行過濾，過濾的同時可能還需要回表，此時效率就會低一些。
