在MySQL中，有很多看上去邏輯相同，但效能卻差異巨大的SQL語句。對這些語句使用不當的話，就會不經意間導致整個資料庫的壓力變大。

我今天挑選了三個這樣的案例和你分享。希望再遇到相似的問題時，你可以做到舉一反三、快速解決問題。

案例一：條件欄位函式操作

假設你現在維護了一個交易系統，其中交易記錄表tradelog包含交易流水號（tradeid）、交易員id（operator）、交易時間（t_modified）等欄位。為了便於描述，我們先忽略其他欄位。這個表的建表語句如下：

mysql> CREATE TABLE `tradelog` (
  `id` int(11) NOT NULL,
  `tradeid` varchar(32) DEFAULT NULL,
  `operator` int(11) DEFAULT NULL,
  `t_modified` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `tradeid` (`tradeid`),
  KEY `t_modified` (`t_modified`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 

假設，現在已經記錄了從2016年初到2018年底的所有資料，運營部門有一個需求是，要統計發生在所有年份中7月份的交易記錄總數。這個邏輯看上去並不複雜，你的SQL語句可能會這麼寫：

mysql> select count(*) from tradelog where month(t_modified)=7;

由於t_modified欄位上有索引，於是你就很放心地在生產庫中執行了這條語句，但卻發現執行了特別久，才返回了結果。

如果你問DBA同事為什麼會出現這樣的情況，他大概會告訴你：如果對欄位做了函式計算，就用不上索引了，這是MySQL的規定。

現在你已經學過了InnoDB的索引結構了，可以再追問一句為什麼？為什麼條件是where t_modified='2018-7-1’的時候可以用上索引，而改成where month(t_modified)=7的時候就不行了？

下面是這個t_modified索引的示意圖。方框上面的數字就是month()函式對應的值。

如果你的SQL語句條件用的是where t_modified='2018-7-1’的話，引擎就會按照上面綠色箭頭的路線，快速定位到 t_modified='2018-7-1’需要的結果。

實際上，B+樹提供的這個快速定位能力，來源於同一層兄弟節點的有序性。

但是，如果計算month()函式的話，你會看到傳入7的時候，在樹的第一層就不知道該怎麼辦了。

也就是說，對索引欄位做函式操作，可能會破壞索引值的有序性，因此優化器就決定放棄走樹搜尋功能。

需要注意的是，優化器並不是要放棄使用這個索引。

在這個例子裡，放棄了樹搜尋功能，優化器可以選擇遍歷主鍵索引，也可以選擇遍歷索引t_modified，優化器對比索引大小後發現，索引t_modified更小，遍歷這個索引比遍歷主鍵索引來得更快。因此最終還是會選擇索引t_modified。

接下來，我們使用explain命令，檢視一下這條SQL語句的執行結果。

key="t_modified"表示的是，使用了t_modified這個索引；我在測試表資料中插入了10萬行資料，rows=100335，說明這條語句掃描了整個索引的所有值；Extra欄位的Using index，表示的是使用了覆蓋索引。

也就是說，由於在t_modified欄位加了month()函式操作，導致了全索引掃描。為了能夠用上索引的快速定位能力，我們就要把SQL語句改成基於欄位本身的範圍查詢。按照下面這個寫法，優化器就能按照我們預期的，用上t_modified索引的快速定位能力了。

mysql> select count(*) from tradelog where
    -> (t_modified >= '2016-7-1' and t_modified<'2016-8-1') or
    -> (t_modified >= '2017-7-1' and t_modified<'2017-8-1') or 
    -> (t_modified >= '2018-7-1' and t_modified<'2018-8-1');

當然，如果你的系統上線時間更早，或者後面又插入了之後年份的資料的話，你就需要再把其他年份補齊。

到這裡我給你說明了，由於加了month()函式操作，MySQL無法再使用索引快速定位功能，而只能使用全索引掃描。

不過優化器在個問題上確實有“偷懶”行為，即使是對於不改變有序性的函式，也不會考慮使用索引。比如，對於select * from tradelog where id + 1 = 10000這個SQL語句，這個加1操作並不會改變有序性，但是MySQL優化器還是不能用id索引快速定位到9999這一行。所以，需要你在寫SQL語句的時候，手動改寫成 where id = 10000 -1才可以。

案例二：隱式型別轉換

接下來我再跟你說一說，另一個經常讓程式設計師掉坑裡的例子。

我們一起看一下這條SQL語句：

mysql> select * from tradelog where tradeid=110717;

交易編號tradeid這個欄位上，本來就有索引，但是explain的結果卻顯示，這條語句需要走全表掃描。你可能也發現了，tradeid的欄位型別是varchar(32)，而輸入的引數卻是整型，所以需要做型別轉換。

那麼，現在這裡就有兩個問題：

1. 資料型別轉換的規則是什麼？

2. 為什麼有資料型別轉換，就需要走全索引掃描？

先來看第一個問題，你可能會說，資料庫裡面型別這麼多，這種資料型別轉換規則更多，我記不住，應該怎麼辦呢？

這裡有一個簡單的方法，看 select “10” > 9的結果：

1. 如果規則是“將字串轉成數字”，那麼就是做數字比較，結果應該是1；

2. 如果規則是“將數字轉成字串”，那麼就是做字串比較，結果應該是0。

驗證結果如圖3所示。

從圖中可知，select “10” > 9返回的是1，所以你就能確認MySQL裡的轉換規則了：在MySQL中，字串和數字做比較的話，是將字串轉換成數字。

這時，你再看這個全表掃描的語句：

mysql> select * from tradelog where tradeid=110717;

就知道對於優化器來說，這個語句相當於：

mysql> select * from tradelog where  CAST(tradid AS signed int) = 110717;

也就是說，這條語句觸發了我們上面說到的規則：對索引欄位做函式操作，優化器會放棄走樹搜尋功能。

現在，我留給你一個小問題，id的型別是int，如果執行下面這個語句，是否會導致全表掃描呢？

select * from tradelog where id="83126";

你可以先自己分析一下，再到資料庫裡面去驗證確認。

接下來，我們再來看一個稍微複雜點的例子。

案例三：隱式字元編碼轉換

假設系統裡還有另外一個表trade_detail，用於記錄交易的操作細節。為了便於量化分析和復現，我往交易日誌表tradelog和交易詳情表trade_detail這兩個表裡插入一些資料。

mysql> CREATE TABLE `trade_detail` (
  `id` int(11) NOT NULL,
  `tradeid` varchar(32) DEFAULT NULL,
  `trade_step` int(11) DEFAULT NULL, /*操作步驟*/
  `step_info` varchar(32) DEFAULT NULL, /*步驟資訊*/
  PRIMARY KEY (`id`),
  KEY `tradeid` (`tradeid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into tradelog values(1, 'aaaaaaaa', 1000, now());
insert into tradelog values(2, 'aaaaaaab', 1000, now());
insert into tradelog values(3, 'aaaaaaac', 1000, now());

insert into trade_detail values(1, 'aaaaaaaa', 1, 'add');
insert into trade_detail values(2, 'aaaaaaaa', 2, 'update');
insert into trade_detail values(3, 'aaaaaaaa', 3, 'commit');
insert into trade_detail values(4, 'aaaaaaab', 1, 'add');
insert into trade_detail values(5, 'aaaaaaab', 2, 'update');
insert into trade_detail values(6, 'aaaaaaab', 3, 'update again');
insert into trade_detail values(7, 'aaaaaaab', 4, 'commit');
insert into trade_detail values(8, 'aaaaaaac', 1, 'add');
insert into trade_detail values(9, 'aaaaaaac', 2, 'update');
insert into trade_detail values(10, 'aaaaaaac', 3, 'update again');
insert into trade_detail values(11, 'aaaaaaac', 4, 'commit');

這時候，如果要查詢id=2的交易的所有操作步驟資訊，SQL語句可以這麼寫：

mysql> select d.* from tradelog l, trade_detail d where d.tradeid=l.tradeid and l.id=2; /*語句Q1*/

我們一起來看下這個結果：

1. 第一行顯示優化器會先在交易記錄表tradelog上查到id=2的行，這個步驟用上了主鍵索引，rows=1表示只掃描一行；

2. 第二行key=NULL，表示沒有用上交易詳情表trade_detail上的tradeid索引，進行了全表掃描。

在這個執行計劃裡，是從tradelog表中取tradeid欄位，再去trade_detail表裡查詢匹配欄位。因此，我們把tradelog稱為驅動表，把trade_detail稱為被驅動表，把tradeid稱為關聯欄位。

接下來，我們看下這個explain結果表示的執行流程：

圖中：

• 第1步，是根據id在tradelog表裡找到L2這一行；
• 第2步，是從L2中取出tradeid欄位的值；
• 第3步，是根據tradeid值到trade_detail表中查詢條件匹配的行。explain的結果裡面第二行的key=NULL表示的就是，這個過程是通過遍歷主鍵索引的方式，一個一個地判斷tradeid的值是否匹配。

進行到這裡，你會發現第3步不符合我們的預期。因為表trade_detail裡tradeid欄位上是有索引的，我們本來是希望通過使用tradeid索引能夠快速定位到等值的行。但，這裡並沒有。

如果你去問DBA同學，他們可能會告訴你，因為這兩個表的字符集不同，一個是utf8，一個是utf8mb4，所以做表連線查詢的時候用不上關聯欄位的索引。這個回答，也是通常你搜索這個問題時會得到的答案。

但是你應該再追問一下，為什麼字符集不同就用不上索引呢？

我們說問題是出在執行步驟的第3步，如果單獨把這一步改成SQL語句的話，那就是：

mysql> select * from trade_detail where tradeid=$L2.tradeid.value; 

其中，$L2.tradeid.value的字符集是utf8mb4。

參照前面的兩個例子，你肯定就想到了，字符集utf8mb4是utf8的超集，所以當這兩個型別的字串在做比較的時候，MySQL內部的操作是，先把utf8字串轉成utf8mb4字符集，再做比較。

這個設定很好理解，utf8mb4是utf8的超集。類似地，在程式設計語言裡面，做自動型別轉換的時候，為了避免資料在轉換過程中由於截斷導致資料錯誤，也都是“按資料長度增加的方向”進行轉換的。

因此， 在執行上面這個語句的時候，需要將被驅動資料表裡的欄位一個個地轉換成utf8mb4，再跟L2做比較。

也就是說，實際上這個語句等同於下面這個寫法：

select * from trade_detail  where CONVERT(traideid USING utf8mb4)=$L2.tradeid.value; 

CONVERT()函式，在這裡的意思是把輸入的字串轉成utf8mb4字符集。

這就再次觸發了我們上面說到的原則：對索引欄位做函式操作，優化器會放棄走樹搜尋功能。

到這裡，你終於明確了，字符集不同只是條件之一，連線過程中要求在被驅動表的索引欄位上加函式操作，是直接導致對被驅動表做全表掃描的原因。

作為對比驗證，我給你提另外一個需求，“查詢trade_detail表裡id=4的操作，對應的操作者是誰”，再來看下這個語句和它的執行計劃。

mysql>select l.operator from tradelog l , trade_detail d where d.tradeid=l.tradeid and d.id=4;

這個語句裡trade_detail 表成了驅動表，但是explain結果的第二行顯示，這次的查詢操作用上了被驅動表tradelog裡的索引(tradeid)，掃描行數是1。

這也是兩個tradeid欄位的join操作，為什麼這次能用上被驅動表的tradeid索引呢？我們來分析一下。

假設驅動表trade_detail裡id=4的行記為R4，那麼在連線的時候（圖5的第3步），被驅動表tradelog上執行的就是類似這樣的SQL 語句：

select operator from tradelog  where traideid =$R4.tradeid.value; 

這時候$R4.tradeid.value的字符集是utf8, 按照字符集轉換規則，要轉成utf8mb4，所以這個過程就被改寫成：

select operator from tradelog  where traideid =CONVERT($R4.tradeid.value USING utf8mb4); 

你看，這裡的CONVERT函式是加在輸入引數上的，這樣就可以用上被驅動表的traideid索引。

理解了原理以後，就可以用來指導操作了。如果要優化語句

select d.* from tradelog l, trade_detail d where d.tradeid=l.tradeid and l.id=2;

的執行過程，有兩種做法：

• 比較常見的優化方法是，把trade_detail表上的tradeid欄位的字符集也改成utf8mb4，這樣就沒有字符集轉換的問題了。

alter table trade_detail modify tradeid varchar(32) CHARACTER SET utf8mb4 default null;

• 如果能夠修改欄位的字符集的話，是最好不過了。但如果資料量比較大， 或者業務上暫時不能做這個DDL的話，那就只能採用修改SQL語句的方法了。

mysql> select d.* from tradelog l , trade_detail d where d.tradeid=CONVERT(l.tradeid USING utf8) and l.id=2; 

這裡，我主動把 l.tradeid轉成utf8，就避免了被驅動表上的字元編碼轉換，從explain結果可以看到，這次索引走對了。

小結

今天我給你舉了三個例子，其實是在說同一件事兒，即：對索引欄位做函式操作，可能會破壞索引值的有序性，因此優化器就決定放棄走樹搜尋功能。

第二個例子是隱式型別轉換，第三個例子是隱式字元編碼轉換，它們都跟第一個例子一樣，因為要求在索引欄位上做函式操作而導致了全索引掃描。

MySQL的優化器確實有“偷懶”的嫌疑，即使簡單地把where id+1=1000改寫成where id=1000-1就能夠用上索引快速查詢，也不會主動做這個語句重寫。

因此，每次你的業務程式碼升級時，把可能出現的、新的SQL語句explain一下，是一個很好的習慣。

最後，又到了思考題時間。

今天我留給你的課後問題是，你遇到過別的、類似今天我們提到的效能問題嗎？你認為原因是什麼，又是怎麼解決的呢？

你可以把你經歷和分析寫在留言區裡，我會在下一篇文章的末尾選取有趣的評論跟大家一起分享和分析。感謝你的收聽，也歡迎你把這篇文章分享給更多的朋友一起閱讀。

上期問題時間

我在上篇文章的最後，留給你的問題是：我們文章中最後的一個方案是，通過三次limit Y,1 來得到需要的資料，你覺得有沒有進一步的優化方法。

這裡我給出一種方法，取Y1、Y2和Y3裡面最大的一個數，記為M，最小的一個數記為N，然後執行下面這條SQL語句：

mysql> select * from t limit N, M-N+1;

再加上取整個表總行數的C行，這個方案的掃描行數總共只需要C+M+1行。

當然也可以先取回id值，在應用中確定了三個id值以後，再執行三次where id=X的語句也是可以的。@倪大人 同學在評論區就提到了這個方法。