mysql 查看當前正在執行的語句;
查看當前正在執行的語句 show processlist：
root@localhost [(none)]>show processlist;
+----+-------------+---------------------+------+-------------+-------+---------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-------------+---------------------+------+-------------+-------+---------------------------------------------------------------+------------------+
| 3 | system user | | NULL | Connect | 53528 | Waiting for master to send event | NULL |
| 4 | system user | | NULL | Connect | 53528 | Slave has read all relay log; waiting for more updates | NULL |
| 5 | repluser | 192.168.30.37:51622 | NULL | Binlog Dump | 53496 | Master has sent all binlog to slave; waiting for more updates | NULL |
| 13 | root | localhost | NULL | Query | 1 | starting | show processlist |
+----+-------------+---------------------+------+-------------+-------+---------------------------------------------------------------+------------------+
4 rows in set (0.22 sec)
結束正在執行的語句進程 kill 進程id
select @@global.query_cache_size;
set @@global.query_cache_size=16777216;
stream {
server {
listen 3336;
proxy_pass db;
}
upstream db {
server 10.211.7.11:3306;
server 10.211.7.12:3306 backup;
}
}
mysql找到所有索引
SELECT a.TABLE_SCHEMA,
a.TABLE_NAME,
a.index_name,
GROUP_CONCAT(column_name ORDER BY seq_in_index) AS Columns
FROM information_schema.statistics a
GROUP BY a.TABLE_SCHEMA,a.TABLE_NAME,a.index_name
mysql主從時不時進入Slave_SQL_Running_State:system lock，然後恢復到 Slave has read all relay log; waiting for more updates
五、system lock 延遲的原因
這裏先直接給出原因供大家直接參考，簡單的說從庫出現 system lock 應該視爲正在幹活，而不是名稱看到的“lock”，這是由於 slave 端不存在語句（row 格式）的執行，都是 Event 的直接 apply，狀態沒有切換的機會，也可以認爲是 slave 端狀態劃分不嚴謹，其實做一個 pstack 就能完全看出問題。下面是產生的必要條件：
由於大量的小事物，比如 UPDATE/DELETE table where 處理一行數據，這會出現只包含一行數據庫的 DML event 的語句，如果 table 是一張大表，則會加劇這種可能。
這個表上沒有主鍵或者唯一鍵，問題加劇。
由於類似 Innodb lock 堵塞，也就是 slave 從庫修改了數據同時和 sql_thread 也在修改同樣的數據，問題加劇。
確實 I/O 扛不住了，可以嘗試修改參數。
如果是大量的表沒有主鍵或者唯一鍵可以考慮修改參數 slave_rows_search_algorithms 試試。關於 slave_rows_search_algorithms 在我的系列中有一章詳細討論，這裏不做贅述。
這裏還特地請教了阿里的印風兄驗證了一下 mysql_lock_tables 是 myisam 實現表鎖的函數 Innodb 會設置爲共享鎖。
這裏我們先拋開 query event/map event 等。只考慮 DML event，下面就是 system lock 出現的流程：
如果一個小事物只有一條 DML event 的場景下邏輯如下：
->進入reading eventfrom the relay log狀態
->讀取一條event(參考next_event函數)
->進入system lock狀態
->Innodb層進行查找和修改數據
如果是一個大事物則包含了多條 DML event 的場景邏輯如下：
->進入reading eventfrom the relay log狀態
->讀取一條event(參考next_event函數)
->進入system lock狀態
->Innodb層進行查找和修改數據
->進入reading eventfrom the relay log狀態
->讀取一條event(參考next_event函數)
->Innodb層進行查找和修改數據
->進入reading eventfrom the relay log狀態
->讀取一條event(參考next_event函數)
->Innodb層進行查找和修改數據
....直到本事物event執行完成
因此我們看到對於一個小事物我們的 sql_thread 會在加 system lock 的情況下進行對數據進行查找和修改。
因此得出了我的結論，同時如果是 Innodb 層鎖造成的 sqlthread 堵塞也會在持有 system lock 的狀態下。但是對於一個大事物則不一樣，雖然出現同樣的問題，但是其狀態是 reading event from the relay log。
所以如果出現 system lock 一般就是考慮前文給出的結論。