昨晚我正在床上睡得著著的，突然來了一條短信，
什么？線上的訂單無法取消！
我趕緊登錄線上系統，查看業務日志，
發現有MySQL鎖超時的錯誤日志，
不用想，肯定有另一個事務正在修改這條訂單，持有這條訂單的鎖，
導致當前事務獲取不到鎖，一直等待，直到超過鎖超時時間，然后報錯，
既然問題已經清楚了，接下來就輪到怎么排查一下到底是哪個事務正在持有這條訂單的鎖，
好在MySQL提供了豐富的工具，幫助我們排查鎖競爭問題，
現場復現一個這個問題：
創建一張用戶表，造點資料：
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵ID',
`name` varchar(50) NOT NULL DEFAULT '' COMMENT '姓名',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
事務1，更新id=1的用戶姓名，不提交事務：
begin;
update user set name='一燈' where id=1;
事務2，洗掉id=1的資料，這時候會產生鎖等待：
begin;
delete from user where id=1;
接下來，我們就通過MySQL提供的鎖競爭統計表，排查一下鎖等待問題：
先查一下鎖等待情況：
select * from information_schema.innodb_lock_waits;
可以看到有一個鎖等待的事務，
然后再查一下正在競爭的鎖有哪些？
select * from information_schema.innodb_locks;
可以看到，MySQL統計的非常詳細：
lock_trx_id 表示事務ID
lock_mode 表示排它鎖還是共享鎖
lock_type 表示鎖定的記錄，還是范圍
lock_table 鎖的表名
lock_index 鎖定的是主鍵索引
再查一下正在執行的事務有哪些？
select * from information_schema.innodb_trx;
可以清楚的看到正在執行的事務有兩個，一個狀態是鎖等待（LOCK WAIT），正在執行的SQL也列印出來了：
delete from user where id=1;
正是事務2的洗掉陳述句，
不用問，第二條，顯示正在運行狀態（RUNNING）的事務就是正在持有鎖的事務1，MySQL執行緒id（trx_mysql_thread_id）是193，
我們用MySQL執行緒id查一下事務執行緒id：
select * from performance_schema.threads where processlist_id=193;
找到對應的事務執行緒id是218，然后再找一下這個執行緒正在執行的SQL陳述句：
select THREAD_ID,CURRENT_SCHEMA,SQL_TEXT
from performance_schema.events_statements_current
where thread_id=218;
可以清楚的看到這個執行緒正在執行的SQL陳述句就是事務1的update陳述句，
持有鎖的SQL陳述句找到了，接下來再去找對應的業務代碼也就輕而易舉了，
以上是基于MySQL5.7版本，在MySQL8.0版本中有些命令已經洗掉了，替換成了其他命令，下篇文章再講一下MySQL8.0怎么定位MySQL鎖超時問題，
文章持續更新，可以微信搜一搜「 一燈架構 」第一時間閱讀更多技術干貨，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/501559.html
標籤：其他