19 | 爲何我只查一行的語句，也執行這麼慢？

通常狀況下，若是我跟你說查詢性能優化，你首先會想到一些複雜的語句，想到查詢須要返回大量的數據。但有些狀況下，「查一行」，也會執行得特別慢。今天，我就跟你聊聊這個有趣的話題，看看什麼狀況下，會出現這個現象。

須要說明的是，若是MySQL數據庫自己就有很大的壓力，致使數據庫服務器CPU佔用率很高或ioutil（IO利用率）很高，這種狀況下全部語句的執行都有可能變慢，不屬於咱們今天的討論範圍。

爲了便於描述，我仍是構造一個表，基於這個表來講明今天的問題。這個表有兩個字段id和c，而且我在裏面插入了10萬行記錄。

mysql> CREATE TABLE `t` (
`id` int(11) NOT NULL,
`c` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;

delimiter ;;
create procedure idata()
begin
declare i int;
set i=1;
while(i<=100000)do
insert into t values(i,i);
set i=i+1;
end while;
end;;
delimiter ;

call idata();

接下來，我會用幾個不一樣的場景來舉例，有些是前面的文章中咱們已經介紹過的知識點，你看看能不能一眼看穿，來檢驗一下吧。

第一類：查詢長時間不返回

如圖1所示，在表t執行下面的SQL語句：

mysql> select * from t where id=1;

查詢結果長時間不返回。

圖1 查詢長時間不返回

通常碰到這種狀況的話，大機率是表t被鎖住了。接下來分析緣由的時候，通常都是首先執行一下show processlist命令，看看當前語句處於什麼狀態。

而後咱們再針對每種狀態，去分析它們產生的緣由、如何復現，以及如何處理。

等MDL鎖

如圖2所示，就是使用show processlist命令查看Waiting for table metadata lock的示意圖。

圖2 Waiting for table metadata lock狀態示意圖

出現這個狀態表示的是，如今有一個線程正在表t上請求或者持有MDL寫鎖，把select語句堵住了。

在第6篇文章《全局鎖和表鎖 ：給表加個字段怎麼有這麼多阻礙？》中，我給你介紹過一種復現方法。但須要說明的是，那個復現過程是基於MySQL 5.6版本的。而MySQL 5.7版本修改了MDL的加鎖策略，因此就不能復現這個場景了。

不過，在MySQL 5.7版本下復現這個場景，也很容易。如圖3所示，我給出了簡單的復現步驟。

圖3 MySQL 5.7中Waiting for table metadata lock的復現步驟

session A 經過lock table命令持有表t的MDL寫鎖，而session B的查詢須要獲取MDL讀鎖。因此，session B進入等待狀態。

這類問題的處理方式，就是找到誰持有MDL寫鎖，而後把它kill掉。

可是，因爲在show processlist的結果裏面，session A的Command列是「Sleep」，致使查找起來很不方便。不過有了performance_schema和sys系統庫之後，就方便多了。（MySQL啓動時須要設置performance_schema=on，相比於設置爲off會有10%左右的性能損失)

經過查詢sys.schema_table_lock_waits這張表，咱們就能夠直接找出形成阻塞的process id，把這個鏈接用kill 命令斷開便可。

圖4 查獲加表鎖的線程id

等flush

接下來，我給你舉另一種查詢被堵住的狀況。

我在表t上，執行下面的SQL語句：

mysql> select * from information_schema.processlist where id=1;

這裏，我先賣個關子。

你能夠看一下圖5。我查出來這個線程的狀態是Waiting for table flush，你能夠設想一下這是什麼緣由。

圖5 Waiting for table flush狀態示意圖

這個狀態表示的是，如今有一個線程正要對錶t作flush操做。MySQL裏面對錶作flush操做的用法，通常有如下兩個：

flush tables t with read lock;

flush tables with read lock;

這兩個flush語句，若是指定表t的話，表明的是隻關閉表t；若是沒有指定具體的表名，則表示關閉MySQL裏全部打開的表。

可是正常這兩個語句執行起來都很快，除非它們也被別的線程堵住了。

因此，出現Waiting for table flush狀態的可能狀況是：有一個flush tables命令被別的語句堵住了，而後它又堵住了咱們的select語句。

如今，咱們一塊兒來複現一下這種狀況，復現步驟如圖6所示：

圖6 Waiting for table flush的復現步驟

在session A中，我故意每行都調用一次sleep(1)，這樣這個語句默認要執行10萬秒，在這期間表t一直是被session A「打開」着。而後，session B的flush tables t命令再要去關閉表t，就須要等session A的查詢結束。這樣，session C要再次查詢的話，就會被flush 命令堵住了。

圖7是這個復現步驟的show processlist結果。這個例子的排查也很簡單，你看到這個show processlist的結果，確定就知道應該怎麼作了。

圖 7 Waiting for table flush的show processlist 結果

等行鎖

如今，通過了表級鎖的考驗，咱們的select 語句終於來到引擎裏了。

mysql> select * from t where id=1 lock in share mode;

上面這條語句的用法你也很熟悉了，咱們在第8篇《事務究竟是隔離的仍是不隔離的？》文章介紹當前讀時提到過。

因爲訪問id=1這個記錄時要加讀鎖，若是這時候已經有一個事務在這行記錄上持有一個寫鎖，咱們的select語句就會被堵住。

復現步驟和現場以下：

圖 8 行鎖復現

圖 9 行鎖show processlist 現場

顯然，session A啓動了事務，佔有寫鎖，還不提交，是致使session B被堵住的緣由。

這個問題並不難分析，但問題是怎麼查出是誰佔着這個寫鎖。若是你用的是MySQL 5.7版本，能夠經過sys.innodb_lock_waits 表查到。

查詢方法是：

mysql> select * from t sys.innodb_lock_waits where locked_table=`'test'.'t'`\G

圖10 經過sys.innodb_lock_waits 查行鎖

能夠看到，這個信息很全，4號線程是形成堵塞的罪魁禍首。而幹掉這個罪魁禍首的方式，就是KILL QUERY 4或KILL 4。

不過，這裏不該該顯示「KILL QUERY 4」。這個命令表示中止4號線程當前正在執行的語句，而這個方法實際上是沒有用的。由於佔有行鎖的是update語句，這個語句已是以前執行完成了的，如今執行KILL QUERY，沒法讓這個事務去掉id=1上的行鎖。

實際上，KILL 4纔有效，也就是說直接斷開這個鏈接。這裏隱含的一個邏輯就是，鏈接被斷開的時候，會自動回滾這個鏈接裏面正在執行的線程，也就釋放了id=1上的行鎖。

第二類：查詢慢

通過了重重封「鎖」，咱們再來看看一些查詢慢的例子。

先來看一條你必定知道緣由的SQL語句：

mysql> select * from t where c=50000 limit 1;

因爲字段c上沒有索引，這個語句只能走id主鍵順序掃描，所以須要掃描5萬行。

做爲確認，你能夠看一下慢查詢日誌。注意，這裏爲了把全部語句記錄到slow log裏，我在鏈接後先執行了 set long_query_time=0，將慢查詢日誌的時間閾值設置爲0。

圖11 全表掃描5萬行的slow log

Rows_examined顯示掃描了50000行。你可能會說，不是很慢呀，11.5毫秒就返回了，咱們線上通常都配置超過1秒纔算慢查詢。但你要記住：壞查詢不必定是慢查詢。咱們這個例子裏面只有10萬行記錄，數據量大起來的話，執行時間就線性漲上去了。

掃描行數多，因此執行慢，這個很好理解。

可是接下來，咱們再看一個只掃描一行，可是執行很慢的語句。

如圖12所示，是這個例子的slow log。能夠看到，執行的語句是

mysql> select * from t where id=1；

雖然掃描行數是1，但執行時間卻長達800毫秒。

圖12 掃描一行卻執行得很慢

是否是有點奇怪呢，這些時間都花在哪裏了？

若是我把這個slow log的截圖再往下拉一點，你能夠看到下一個語句，select * from t where id=1 lock in share mode，執行時掃描行數也是1行，執行時間是0.2毫秒。

圖 13 加上lock in share mode的slow log

看上去是否是更奇怪了？按理說lock in share mode還要加鎖，時間應該更長才對啊。

可能有的同窗已經有答案了。若是你尚未答案的話，我再給你一個提示信息，圖14是這兩個語句的執行輸出結果。

圖14 兩個語句的輸出結果

第一個語句的查詢結果裏c=1，帶lock in share mode的語句返回的是c=1000001。看到這裏應該有更多的同窗知道緣由了。若是你仍是沒有頭緒的話，也彆着急。我先跟你說明一下復現步驟，再分析緣由。

圖15 復現步驟

你看到了，session A先用start transaction with consistent snapshot命令啓動了一個事務，以後session B纔開始執行update 語句。

session B執行完100萬次update語句後，id=1這一行處於什麼狀態呢？你能夠從圖16中找到答案。

圖16 id=1的數據狀態

session B更新完100萬次，生成了100萬個回滾日誌(undo log)。

帶lock in share mode的SQL語句，是當前讀，所以會直接讀到1000001這個結果，因此速度很快；而select * from t where id=1這個語句，是一致性讀，所以須要從1000001開始，依次執行undo log，執行了100萬次之後，纔將1這個結果返回。

注意，undo log裏記錄的實際上是「把2改爲1」，「把3改爲2」這樣的操做邏輯，畫成減1的目的是方便你看圖。

小結

今天我給你舉了在一個簡單的表上，執行「查一行」，可能會出現的被鎖住和執行慢的例子。這其中涉及到了表鎖、行鎖和一致性讀的概念。

在實際使用中，碰到的場景會更復雜。但大同小異，你能夠按照我在文章中介紹的定位方法，來定位並解決問題。

最後，我給你留一個問題吧。

咱們在舉例加鎖讀的時候，用的是這個語句，select * from t where id=1 lock in share mode。因爲id上有索引，因此能夠直接定位到id=1這一行，所以讀鎖也是隻加在了這一行上。

但若是是下面的SQL語句，

begin;
select * from t where c=5 for update;
commit;

這個語句序列是怎麼加鎖的呢？加的鎖又是何時釋放呢？

你能夠把你的觀點和驗證方法寫在留言區裏，我會在下一篇文章的末尾給出個人參考答案。感謝你的收聽，也歡迎你把這篇文章分享給更多的朋友一塊兒閱讀。

上期問題時間

在上一篇文章最後，我留給你的問題是，但願你能夠分享一下以前碰到過的、與文章中相似的場景。

@封建的風 提到一個有趣的場景，值得一說。我把他的問題重寫一下，表結構以下：

mysql> CREATE TABLE `table_a` (
`id` int(11) NOT NULL,
`b` varchar(10) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `b` (`b`)
) ENGINE=InnoDB;

假設如今表裏面，有100萬行數據，其中有10萬行數據的b的值是’1234567890’， 假設如今執行語句是這麼寫的:

mysql> select * from table_a where b='1234567890abcd';

這時候，MySQL會怎麼執行呢？

最理想的狀況是，MySQL看到字段b定義的是varchar(10)，那確定返回空呀。惋惜，MySQL並無這麼作。

那要不，就是把’1234567890abcd’拿到索引裏面去作匹配，確定也沒可以快速判斷出索引樹b上並無這個值，也很快就能返回空結果。

但實際上，MySQL也不是這麼作的。

這條SQL語句的執行很慢，流程是這樣的：

1. 在傳給引擎執行的時候，作了字符截斷。由於引擎裏面這個行只定義了長度是10，因此只截了前10個字節，就是’1234567890’進去作匹配；

2. 這樣知足條件的數據有10萬行；

3. 由於是select *， 因此要作10萬次回表；

4. 可是每次回表之後查出整行，到server層一判斷，b的值都不是’1234567890abcd’;

5. 返回結果是空。

這個例子，是咱們文章內容的一個很好的補充。雖然執行過程當中可能通過函數操做，可是最終在拿到結果後，server層仍是要作一輪判斷的。