背景
大家有沒有遇到這樣的情況
某個SQL執行特別慢，導致整個transaction一直處於running階段
某個Session的SQL已經執行完了，但是遲遲沒有commit，一直處於sleep階段
某個Session處於lock wait階段，遲遲沒有結束
以上，大部分原因都是大事務導致的，接下來我們好好聊聊相關話題
關鍵字
環境
- MySQL5.7.22
低版本MySQL這邊不再考慮，就像還有使用SAS盤的公司一樣，費時費力，MySQL5.7+ 標配 - InnoDB存儲引擎
-
CentOS 6
大事務的相關特徵 - transaction開啓到結束的時間非常長，我們這邊舉例爲10s
- 正在執行的事務
- 未提交的事務
實戰
如何監控那些正在執行的事務 - select * from sys.processlist
- show processlist
- select * from information_schema.processlist
- select * from sys.session
- select * from information_schema.innodb_trx;
- select from performance_schema.events_statements_current
如何監控那些未提交的事務
1
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:58
wait_age: 00:00:03
wait_age_secs: 3
locked_table: lc.lc_1
locked_index: GEN_CLUST_INDEX
locked_type: RECORD
waiting_trx_id: 1592102
waiting_trx_started: 2018-06-26 11:49:58
waiting_trx_age: 00:00:03
waiting_trx_rows_locked: 2
waiting_trx_rows_modified: 0
waiting_pid: 3
waiting_query: update lc_1 set id=4 where id = 1
waiting_lock_id: 1592102:32:3:4
waiting_lock_mode: X
blocking_trx_id: 1592100
blocking_pid: 2
blocking_query: NULL
blocking_lock_id: 1592100:32:3:4
blocking_lock_mode: X
blocking_trx_started: 2018-06-26 11:49:08
blocking_trx_age: 00:00:53
blocking_trx_rows_locked: 1
blocking_trx_rows_modified: 1
sql_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
工慾善其事必先利其器
1、具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加羣。
2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加羣。
3、如果沒有工作經驗，但基礎非常紮實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加羣。
4、覺得自己很牛B，一般需求都能搞定。但是所學的知識點沒有系統化，很難在技術領域繼續突破的可以加羣
5.羣號：高級架構羣 230419550 備註好信息！
6.阿里Java高級架構師直播講解知識點，分享知識，多年工作經驗的梳理和總結，帶着大家全面、科學地建立自己的技術體系和技術認知
最後，希望找工作的朋友都能找到一份滿意的工作。下面具體列出了面試常見的知識點，供大家參考，希望對你有所幫助。