問題的背景:在實際使用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裡對照一下就能看到了。