long transaction

背景

大家有沒有遇到這樣的情況

某個SQL執行特別慢，導致整個transaction一直處于running階段

某個Session的SQL已經執行完了，但是遲遲沒有commit，一直處于sleep階段

某個Session處于lock wait階段，遲遲沒有結束

以上，大部分原因都是大事務導致的，接下來我們好好聊聊相關話題

關鍵字

• 環境

1. MySQL5.7.22低版本MySQL這邊不再考慮，就像還有使用SAS盤的公司一樣，費時費力，MySQL5.7+ 標配2. InnoDB存儲引擎3. CentOS 6

• 大事務的相關特征

1. transaction開啟到結束的時間非常長，我們這邊舉例為10s 2. 正在執行的事務 3. 未提交的事務

實戰

• 如何監控那些正在執行的事務

1. select * from sys.processlist 2. show processlist 3. select * from information_schema.processlist 4. select * from sys.session 5. select * from information_schema.innodb_trx; 6. select * from performance_schema.events_statements_current

• 如何監控那些未提交的事務

select * from information_schema.innodb_trx

• 如何兩者結合

select trx_id,INNODB_TRX.trx_state,INNODB_TRX.trx_started,se.conn_id as processlist_id,trx_lock_memory_bytes,se.user,se.command,se.state,se.current_statement,se.last_statement from information_schema.INNODB_TRX,sys.session as se where trx_mysql_thread_id=conn_id;+---------+-----------+---------------------+----------------+-----------------------+------+---------+----------+-----------------------------------+-----------------------------------+ | trx_id | trx_state | trx_started | processlist_id | trx_lock_memory_bytes | user | command | state | current_statement | last_statement | +---------+-----------+---------------------+----------------+-----------------------+------+---------+----------+-----------------------------------+-----------------------------------+ | 1592104 | LOCK WAIT | 2018-06-26 11:51:17 | 3 | 1136 | NULL | Query | updating | update lc_1 set id=4 where id = 1 | NULL | | 1592100 | RUNNING | 2018-06-26 11:49:08 | 2 | 1136 | NULL | Sleep | NULL | NULL | update lc_1 set id=3 where id = 1 | +---------+-----------+---------------------+----------------+-----------------------+------+---------+----------+-----------------------------------+-----------------------------------+

大家可以看到，通過這個可以立馬發現事務語句處于running階段 ， 哪些事務處于lock wait階段 ， 如果遇到這種情況，我們應該如何處理呢？
聰明的你，一定會去根據trx_started去尋找蛛絲馬跡，可是如果再生產環境中，這是一件非常復雜和繁忙的事情
不過沒關系，我們還有神器可以使用

• 如何快速解決鎖等待問題

dba:sys> select * from sys.innodb_lock_waits\G *************************** 1. row ***************************wait_started: 2018-06-26 11:49:58wait_age: 00:00:03wait_age_secs: 3locked_table: `lc`.`lc_1`locked_index: GEN_CLUST_INDEXlocked_type: RECORDwaiting_trx_id: 1592102waiting_trx_started: 2018-06-26 11:49:58waiting_trx_age: 00:00:03waiting_trx_rows_locked: 2waiting_trx_rows_modified: 0waiting_pid: 3waiting_query: update lc_1 set id=4 where id = 1waiting_lock_id: 1592102:32:3:4waiting_lock_mode: Xblocking_trx_id: 1592100blocking_pid: 2blocking_query: NULLblocking_lock_id: 1592100:32:3:4blocking_lock_mode: Xblocking_trx_started: 2018-06-26 11:49:08blocking_trx_age: 00:00:53blocking_trx_rows_locked: 1blocking_trx_rows_modified: 1sql_kill_blocking_query: KILL QUERY 2 sql_kill_blocking_connection: KILL 2

MySQL最終非常貼心都連kill SQL 語句都生產了，你只需要復制、粘貼即可

細心的你會發現，通過innodb_lock_waits你只能看到被lock的語句，但是看不到是哪個query語句擁有的鎖，這又是為什么呢？

不賣關子，因為擁有鎖的事務中可能擁有多條query語句，也可能已經執行完，但是沒有commit，所以無法給出所有query語句。

那怎么辦呢？哈哈，如果幸運的話，你可以根據我上述的案例 current_statement，last_statement 得到答案。

再換句話說，即便沒有找到那條query，也不妨礙你解決當前的問題哈

總結

MySQL5.7 默默的提供了非常多的實用工具和新特性，需要DBA們去挖掘和探索。將看似平淡無奇的特性挖掘成黑武器，你才能成為那閃著光芒的Top5 MySQLer

工欲善其事必先利其器

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的MySQL运维系列 之 如何监控大事务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。