高效能MySQL讀書筆記：找出誰持有鎖

周末重讀了一遍《高效能MySQL》，發現有些知識點看過便忘了，沒有實際動手操作一遍就是記不牢，所以今天動手操作了一下“找出誰持有鎖”，並把實驗步驟記錄下來，有興趣的網友可以參照一二。

問題的背景：在實際使用MySQL時，如果訪問量比較大，那麼很可能會出現大量Locked狀態的進程，但是卻不能方便的識別是哪條SQL引起的問題，很多人遇到此類問題時，多半是通過PhpMyAdmin查詢可疑SQL，然後KILL掉，但問題是可疑SQL可能會很多，這樣逐一嘗試太過笨拙，有的人一怒之下很可能會重啟MySQL，但如此治標不治本的方法肯定更不可取。

開始實驗，在test資料庫先建立一個測試表foo（注意：是MyISAM表類型），添加若干資料：

CREATE TABLE IF NOT EXISTS `foo` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`str` varchar(100) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM;

INSERT INTO `foo` (`id`, `str`) VALUES
(1, 'a'),
(2, 'b');

開啟一個MySQL命令列終端：

mysql> USE test;
mysql> SELECT SLEEP(12345) FROM foo;

再開啟一個MySQL命令列終端：

mysql> USE test;
mysql> UPDATE foo SET str='bar';

此時執行SHOW PROCESSLIST，可以看到已經出現Locked現象了：

10  User sleep  SELECT sleep(12345) FROM foo
20  Locked      UPDATE foo SET str = 'bar'

當然，我們知道是SLEEP堵塞了UPDATE，但如果不是這個實驗，面對同樣的情況，比如說幾百個SQL查詢同時映入眼帘，我們如何來判斷呢？此時沒人能打包票，只能瞎蒙了，經驗有時候很重要，但我們還需要明確的命令，在這裡就是：

mysqladmin debug

注意：如何你沒有設定“.my.cnf”設定檔的話，可能需要輸入使用者名稱和密碼參數

命令執行後，不會有任何明確的輸出，不要著急，有價值的東西此時已經被儲存到了錯誤記錄檔裡：

mysql> SHOW VARIABLES LIKE 'log_error';

找到錯誤記錄檔的具體路徑後，開啟，查看日誌的最後部分：

10  test.foo    Locked - read       Low priority read lock
20  test.foo    Waiting - write     High priority write lock

如此，我們就能看到id是10的SQL堵塞了id是20的SQL，至於具體的SQL，到SHOW PROCESSLIST裡對照一下就能看到了。