按照這些優化技巧來寫 SQL,連公司 DBA 也鼓掌稱讚!
阿新 • • 發佈:2020-05-09
# 原文連結:[按照這些優化技巧來寫 SQL,連公司 DBA 也鼓掌稱讚!](https://blog.csdn.net/Howinfun/article/details/106019231)
剛畢業的我們,都以為使用 MySQL 是非常的簡單的,無非都是照著 【**select from where group by order by**】 這個格式套來套去;從來不會關注 SQL 的耗費時長,更不會關注查詢的效能。
但是當用戶量上來了,表資料不斷暴增,導致我們以前寫的 SQL 的查詢時間越來越長,最後還被 DBA 和領導瘋狂吐槽一波。那麼,此時我們是不是應該學習一下如何去優化我們的爛 SQL 呢?
下面,我將從多方面去深入講解如何優化 SQL 。
## 一、索引優化
索引的資料結構是 B+Tree,而 B+Tree 的查詢效能是比較高的,所以建立索引能提升 SQL 的查詢效能。
##### 1、建立普通索引
對經常出現在 where 關鍵字後面的表字段建立對應的索引。
##### 2、建立複合索引
如果 where 關鍵字後面常出現的有幾個欄位,可以建立對應的 **複合索引**。要注意可以優化的一點是:將單獨出現最多的欄位放在前面。
例如現在我們有兩個欄位 a 和 b 經常會同時出現在 where 關鍵字後面:
```sql
select * from t where a = 1 and b = 2; \* Q1 *\
```
也有很多 SQL 會單獨使用欄位 a 作為查詢條件:
```sql
select * from t where a = 2; \* Q2 *\
```
此時,我們可以建立複合索引 `index(a,b)`。因為不但 Q1 可以利用複合索引,Q2 也可以利用複合索引。
##### 3、最左字首匹配原則
如果我們使用的是複合索引,應該儘量遵循 **最左字首匹配原則**。MySQL 會一直向右匹配直到遇到範圍查詢(>、<、between、like)就停止匹配。
假如此時我們有一條 SQL :
```sql
select * from t where a = 1 and b = 2 and c > 3 and d = 4;
```
那麼我們應該建立的複合索引是:`index(a,b,d,c)` 而不是 `index(a,b,c,d)`。因為欄位 c 是範圍查詢,當 MySQL 遇到範圍查詢就停止索引的匹配了。
大家也注意到了,其實 a,b,d 在 SQL 的位置是可以任意調整的,優化器會找到對應的複合索引。
還要注意一點的是:**最左字首匹配原則不但是複合索引的最左 N 個欄位;也可以是單列(字串型別)索引的最左 M 個字元。**
- 例如我們常說的 like 關鍵字,儘量不要使用全模糊查詢,因為這樣用不到索引;
- 所以建議是使用右模糊查詢:select * from t where name like '李%'(查詢所有姓李的同學的資訊)。
##### 4、索引下推
很多時候,我們還可以複合索引的 **索引下推** 來優化 SQL 。
例如此時我們有一個複合索引:`index(name,age)` ,然後有一條 SQL 如下:
```sql
select * from user where name like '張%' and age = 10 and sex = 'm';
```
根據複合索引的最左字首匹配原則,MySQL 匹配到複合索引 `index(name,age)` 的 name 時,就停止匹配了;然後接下來的流程就是根據主鍵回表,判斷 age 和 sex 的條件是否同時滿足,滿足則返回給客戶端。
但是由於有索引下推的優化,匹配到 name 時,不會立刻回表;而是先判斷複合索引 `index(name,age)` 中的 age 是否符合條件;符合條件才進行回表接著判斷 sex 是否滿足,否則會被過濾掉。
那麼藉著 **MySQL 5.6 引入的索引下推優化** ,可以做到減少回表的次數。
##### 5、覆蓋索引
很多時候,我們還可以 **覆蓋索引** 來優化 SQL 。
**情況一**:SQL 只查詢主鍵作為返回值。
主鍵索引(聚簇索引)的葉子節點是整行資料,而普通索引(二級索引)的葉子節點是主鍵的值。
所以當我們的 SQL 只查詢主鍵值,可以直接獲取對應葉子節點的內容,而避免回表。
**情況二**:SQL 的查詢欄位就在索引裡。
複合索引:假如此時我們有一個複合索引 `index(name,age)` ,有一條 SQL 如下:
```sql
select name,age from t where name like '張%';
```
由於是欄位 name 是右模糊查詢所以可以走複合索引,然後匹配到 name 時,不需要回表,因為 SQL 只是查詢欄位 name 和 age,所以直接返回索引值就 ok 了。
##### 6、普通索引
儘量 **使用普通索引** 而不是唯一索引。
首先,普通索引和唯一索引的查詢效能其實不會相差很多;當然了,前提是要查詢的記錄都在同一個資料頁中,否則普通索引的效能會慢很多。
但是,普通索引的更新操作效能比唯一索引更好;其實很簡單,因為普通索引能利用 change buffer 來做更新操作;而唯一索引因為要判斷更新的值是否是唯一的,所以每次都需要將磁碟中的資料讀取到 buffer pool 中。
##### 7、字首索引
我們要學會巧妙的使用 **字首索引**,避免索引值過大。
例如有一個欄位是 addr varchar(255),但是如果一整個建立索引 `[ index(addr) ]`,會很浪費磁碟空間,所以會選擇建立字首索引 `[ index(addr(64)) ]`。
建立字首索引,一定要關注欄位的區分度。例如像身份證號碼這種欄位的區分度很低,只要出生地一樣,前面好多個字元都是一樣的;這樣的話,最不理想時,可能會掃描全表。
字首索引避免不了回表,即無法使用覆蓋索引這個優化點,因為索引值只是欄位的前 n 個字元,需要回表才能判斷查詢值是否和欄位值是一致的。
**怎麼解決?**
1. 倒序儲存:像身份證這種,後面的幾位區分度就非常的高了;我們可以這麼查詢:
```sql
select field_list from t where id_card = reverse('input_id_card_string');
```
2. 增加 hash 欄位併為 hash 欄位新增索引。
##### 8、乾淨的索引列
**索引列不能參與計算**,要保持索引列“乾淨”。
假設我們給表 student 的欄位 birthday 建立了普通索引。
下面的 SQL 語句不能利用到索引來提升執行效率:
```sql
select * from student where DATE_FORMAT(birthday,'%Y-%m-%d') = '2020-02-02';
```
我們應該改成下面這樣:
```sql
select * from student where birthday = STR_TO_DATE('2020-02-02', '%Y-%m-%d');
```
##### 9、擴充套件索引
我們應該儘量 **擴充套件索引**,而不是新增索引,一個表最好不要超過 5 個索引;一個表的索引越多,會導致更新操作更加耗費效能。
## 二、SQL 優化
##### 1、Order By 優化
1. order by 後面的欄位儘量是帶索引的,這樣能避免使用 sort_buffer 進行排序。
- 假如有一條 SQL,根據生日查詢所有學生的資訊:select * from student order by birthday desc;
- 那麼為了提升 SQL 的查詢效能,我們可以為 birthday 欄位建立索引:
```sql
CREATE INDEX index_birthday ON student(birthday);
```
2. select 後面不要帶上不必要的欄位,因為如果單行長度太長導致查詢資料太多,MySQL 會利用 rowid 排序來代替全欄位排序,這樣會導致多了回表的操作。
- 如果我們只是查詢學生的姓名、年齡和生日,千萬不要寫 select *;
- 而是隻查詢需要的欄位:select name, age, birthday from student order by birthday desc;
##### 2、Join 優化
1. 在使用 join 的時候,應該讓小表做驅動表。小表:總資料量最小的表
2. 使用 join 語句,最好保證能利用被驅動表的索引,不然只能使用 BNL(Block Nested-Loop Join)演算法,還不如不用。
3. 啟用 BKA(Batched Key Access) 演算法,使得 NLJ 演算法也能利用上 join_buffer,被驅動表可以批量查詢到符合條件的值,然後可以利用 MMR(Multi-Range Read) 的順序讀盤特性來提升回表效率。
4. 如果一定要用 join,而且被驅動表沒有索引可以使用,那麼我們可以利用臨時表(create temporary table xx(...)engine=innodb;)來讓 BNL 演算法轉為 BKA 演算法,從而提升查詢效能。
5. join_buffer 是一個無序陣列,所以每次判斷都需要遍歷整個 join_buffer。我們可以在業務端實現 hash join 來提升 SQL 的執行速度。
##### 3、Group By 優化
1. 如果對 group by 語句的結果沒有排序要求,要在語句後面加 order by null。
2. 儘量讓 group by 過程用上表的索引,不但不需要臨時表,還不需要額外的排序。
3. 如果 group by 需要統計的資料量不大,儘量只使用記憶體臨時表;也可以通過適當調大 tmp_table_size 引數,來避免用到磁碟臨時表。
4. 如果資料量實在太大,使用 SQL_BIG_RESULT 這個提示,來告訴優化器直接使用排序演算法得到 group by 的結果。
##### 4、OR 優化
在 Innodb 引擎下 or 關鍵字無法使用組合索引。
假設現在關於訂單表有一條 SQL :
```sql
select id,product_name from orders where mobile = '12345678900' or user_id = 6;
```
一般我們為了提升上面 SQL 的查詢效率,會想著為欄位 mobile 和 user_id 建立一個複合索引 index(mobile,user_id);
可是我們使用 explain 可以發現執行計劃裡面並沒有提示到使用複合索引,所以 or 關鍵字無法命中 mobile + user_id 的組合索引。
那麼我們可以分別為兩個欄位建立普通索引,然後採用 union 關鍵字,如下所示:
```sql
(select id,product_name from orders where mobile = '12345678900')
union
(select id,product_name from orders where user_id = 6);
```
此時 mobile 和 user_id 欄位都有索引,查詢才最高效。
##### 5、IN 優化
in 關鍵字適合主表大子表小,exist 關鍵字適合主表小子表大。由於查詢優化器的不斷升級,很多場景這兩者效能差不多一樣了,可以嘗試改為 join 查詢。
假設我們現在有一條 SQL ,要查詢 VIP 使用者的所有訂單資料:
```sql
select id from orders where user_id in (select id from user where level = 'VIP');
```
我們可以發現不會有任何關於索引的優化,所以我們可以採用 join查詢,如下所示:
```sql
select o.id from orders o join user u on o.user_id = u.id and u.level = 'VIP';
```
此時被驅動表應該是 user,那麼可以利用到 user 表的主鍵索引,即可以使用 BKA 演算法來提升 join 查詢的效能。
##### 6、Like 優化
like 用於模糊查詢,但是如果是全模糊查詢,將不能命中對應欄位的索引。
假設現在關於學生表有一條 SQL:
```sql
SELECT name,age,birthday FROM student WHERE name like '%張%';
```
使用 explain 可以發現執行計劃提示查詢未命中索引。
因為本來需求就是查詢姓張的所有同學資訊,所以沒必要使用全模糊查詢,使用右模糊查詢即可。
換成下面的寫法:
```sql
SELECT name,age,birthday FROM student WHERE name like '張%';
```
但是產品經理一定要前後模糊匹配呢?全文索引 FULLTEXT 可以嘗試一下,但是 MySQL 的全文索引不支援中文查詢的。
所以說 Elasticsearch 才是終極武器!
## 三、資料表設計優化
##### 1、資料型別:應該選擇更簡單或者佔用空間更小的型別。
- 整型選擇:可以根據長度選擇 tinyint、smallint、medium_int,而不是直接使用 int。
- 字串選擇:能確定字串長度的,儘量使用 char 型別,而不是變長的 varchar 型別。
- 浮點型選擇:精度要求比較高的使用 decimal 而不是 double;也可以考慮使用 BIGINT 來儲存,小數位儲存可以使用乘以整百來解決。
- 日期選擇:儘量使用 timestamp 而不是 datetime。
##### 2、避免空值:
- NULL 值依然會佔用空間,並且會使索引更新更加複雜,更新 NULL 時容易發生索引分裂的現象。
- 可以使用有意義的值來代替 NULL 值,例如 “none” 字串等等。
##### 3、超長字串:
- 一般超長字串,varchar 難以儲存,我們一般會使用 text 型別。
- 但是 text 型別的欄位儘量避免放在主表中,而是抽出來在子表裡,用業務主鍵關聯。
## 最後
到此結束,如果大家還有更好的優化點,請記得在下方評論,一