概述

自從學習 MySQL 以來，我們一直聽到或者看到很多優化建議，比如說不要用 select * 查詢，用什么字段就查什么字段；建議用自增主鍵來作為表的主鍵，等等。這些建議聽得很多感覺都成了 MySQL 開發的常識了，但是對于這些優化建議，我們有沒有想過為什么要這么做呢？這篇博文我們從 MySQL 的原理出發，來解釋下為什么有這些優化建議？

本文實驗環境 MySQL 5.7.25

預備知識

B+ 樹索引

MySQL 的默認存儲引擎 InnoDB 使用 B+ 樹來存儲數據的，所以在分析優化建議之前，我們有必要了解 B+ 樹索引的基本原理。

上圖是一個 B + 樹索引示意圖（B+ 樹的定義可以看這里），每個節點表示一個磁盤塊，也可以理解為數據庫中的頁。我們來分析下 B+ 樹索引的查找過程，如果我要查詢主鍵為 35 的數據，索引會怎么走呢？首先會判斷 35 小于根節點 37 ，繼續查詢左子樹，判斷 35 大于 22 和 33 那么進入其右子樹，找到了葉子節點 33 ，繼續遍歷找到了 35 ，最后取出其 data 即可。在索引的情況下，查詢 35 只用了3次 IO 操作，這是非常高效的。在真實的場景下，3層的b+樹可以表示上百萬的數據，如果上百萬的數據查找只需要三次IO，性能提高將是巨大的，如果沒有索引，每個數據項都要發生一次IO，那么總共需要百萬次的IO，顯然成本非常非常高。上圖中也是體現了只要維持樹的高度足夠低，IO 操作就會足夠少，IO次數少，查詢性能就會高。

Explain 執行計劃

上圖就是一個 explian 執行計劃，先看看上面各個字段的含義是什么？

• id:?Query Optimizer 所選定的執行計劃中的查詢編號。
• select_type:?所使用的查詢類型，主要有幾種查詢類型：

• table:?顯示執行這一步所訪問的數據庫中的表的名稱。
• partitions:?查詢分區表匹配的分區，非分區表顯示 NULL 。
• type:?查詢表所使用的方式，類型如下：

• 他們的性能由好到差依次是：system > const > eq_ref > ref > full_text > ref_or_null > unique_subquery > index_subquery > range > index_merge > index > all?。
• possible_keys:?查詢可能用到的索引。
• key_len:?用到的索引長度。
• ref:?展示將那些列或者常量與命中的索引比較。
• rows:?執行這次查詢掃描的行數。
• filtered:?過濾行數百分比，最大值是100，當顯示100時候，表示沒有過濾行， rows顯示了檢查的估計行數，乘以過濾百分比將顯示與下表連接的行數。例如，如果行數為1000，過濾條件為50.00（50％），則與下表聯接的行數為1000×50％= 500。
• extra:?執行查詢額外的條件。

掌握了前面這些前置知識，我們來用這些知識分析下經常建議我們的那些MySQL優化建議。

為什么建議使用自增主鍵

當我們每次建立表的時候都在考慮是用自增主鍵呢？還是用 UUID 呢？但是從性能考慮我們還是建議使用自增 Id,為什么呢？主要是由于 MySQL B+ 樹索引性質決定的，數據的新增是要更新索引的，也就是要更新 B+ 樹。換句話說，使用自增Id 和 非自增 Id 哪種更新 B+ 樹更快，成本更低，誰就是更優的選擇。我們來模擬下自增 Id 插入和非自增 Id 插入情況。

自增Id 插入情況：?我們在一個已經有10條數據的 B + 數上插入2條數據，分別是10和11，我們看看樹是如何變化的。

我們這里可以發現兩個特點：

1、自增的數據插入影響的范圍永遠只有最右的子樹，要么直接在子樹插入節點，要么就是子樹分裂，影響其父節點。

2、除了最右子樹，其他子樹的節點都是滿的。

上面兩個特點有什么影響呢？我們根據前面 B+ 樹索引示意圖可以知道，每個點都是一個磁盤塊，操作每個節點相當于進行一次 IO,由于每次插入影響的節點只有最右子樹，那么磁盤 IO 的范圍就可控；最重要一點是除最右子樹，其他子樹的節點都是滿的，這種情況，葉子節點數據的物理連續性會更好，?根據局部性原理,查詢性能也會更高。

非自增 Id 插入情況：

非自增 Id 插入特點對比自增 Id 插入我們很容易就能知道：

1、插入影響節點不可控，無法預知。

2、每個子樹都存在葉子節點不滿的情況。

按照之前的分析思路，我們也就知道了非自增 Id 插入有什么性能劣勢了。由于插入數據影響節點不可控，導致節點分裂的情況就會更頻繁，節點分裂也是 IO 操作，性能自然受到影響。子樹的葉子節點不滿，會導致葉子節點物理連續性不好。最后如果我們是UUID的話，Id 過長，會占用節點空間，每個頁能存儲的節點變少，頁分裂變多，性能也會受到影響。這也是為什么建議使用自增主鍵的原因。

為什么不要使用 select * 查詢

我們經常聽到查詢表，只要查詢自己想要的字段，不需要的字段就不要查詢，嚴禁使用?select *，我們能想到很直觀的理由就是，數據庫要幫你翻譯成每個字段名去查詢，接著查詢多余的字段會占用內存，帶寬等資源。這確實是一個理由，而且這個理由很重要，但是我這里想說的是另外一個原因，覆蓋索引。我之前的一篇索引文章也介紹了覆蓋索引，感興趣的同學可以點擊這里。覆蓋索引的意思是指查詢使用聯合索引覆蓋了要查詢的字段，這樣數據庫不用去進行回表，從而減少IO,提高性能。

這里我用MySQL官方給的示列數據進行一個實驗，數據地址下載可以點擊這里。

我選擇?employees?表數據進行演示，默認數據是沒有聯合索引的，我們加上一個聯合索引：

---employee表結構----------- +------------+---------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------+---------------+------+-----+---------+-------+ | emp_no | int(11) | NO | PRI | NULL | | | birth_date | date | NO | | NULL | | | first_name | varchar(14) | NO | MUL | NULL | | | last_name | varchar(16) | NO | | NULL | | | gender | enum('M','F') | NO | | NULL | | | hire_date | date | NO | | NULL | | +------------+---------------+------+-----+---------+-------+ALTER TABLE employees.employees add Index `idx_first_name_last_name` (first_name,last_name);

查看該表索引情況：show index from employees.employees;

表已經成功創建了first_name?和?last_name的符合索引，我們開啟 profiles 監控 SQL 執行的情況。

SET SESSION profiling = 1;

然后分別執行以下SQL

SELECT first_name,last_name FROM employees.employees WHERE first_name='Eric'; SELECT * FROM employees.employees WHERE first_name='Eric';

查看Profiles；

這里我們看到使用 select * 比 select 字段慢了4倍左右，為什么會這樣呢？我們看看執行計劃。

我們看到兩者的執行計劃幾乎一樣，只有 Extra 有區別，使用字段的 Extra 顯示 using index，這就告訴你只使用索引就找到了想要的數據，因為你的索引就是用?first_name?和?last_name?建立的， 而 select * 它還需要查詢?gender和hire_date字段（主鍵字段不用額外查，輔助索引指向的就是主鍵）,所以它不能不進行回表查詢其他字段，性能差異也是這里。

總結

本文從原理上分析了我們日常的兩點建議，為什么建議使用自增主鍵？為什么不建議使用 select * 查詢？其實主要最終的原因還是和索引相關，既然我們用索引來提高我們的效率就要充分利用它，下面是知識點總結：

1、B+ 樹查詢的效率高低是受其樹高影響，樹的高度越低，查詢IO次數越少，性能相對也就越高。

2、執行計劃的類型由好到差依次是：system > const > eq_ref > ref > full_text > ref_or_null > unique_subquery > index_subquery > range > index_merge > index > all?。

3、自增主鍵的好處就是連續，插入維護的成本相對較低，同時子樹的葉子節點大部分是滿節點，物理連續性好，查詢性能更優。

4、UUID 主鍵長度過長，導致單個子節點存儲的主鍵變少，更平凡的出發頁分裂，影響性能，這也是為什么建議索引不要太長的原因。

5、覆蓋索引是很好的優化技巧，可以讓查詢直接通過索引返回數據，而不用回表，減少IO，提升性能。

參考

1、https://dev.mysql.com/doc/refman/5.7/en/explain-output.html

2、https://dev.mysql.com/doc/refman/5.7/en/explain-output.html#explain-join-types

3、http://blog.codinglabs.org/articles/theory-of-mysql-index.html

來源：開源中國

作者：木木匠

原文：https://my.oschina.net/luozhou/blog/4289527

總結

以上是生活随笔為你收集整理的从原理上理解MySQL的优化建议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。