information_schema系列八(事物,鎖)


今天我們主要看一下MySQL information_schema里面的關於innodb的鎖和事物的兩三個系統表:
看一下鎖對應的sql:
select * from innodb_lock_waits;
select * from innodb_locks limit 2\G
select * from information_schema.innodb_trx\G
select * from information_schema.innodb_trx where trx_id = 45734628\G
SELECT
lw.requesting_trx_id AS request_ID,
 trx.trx_mysql_thread_id as request_mysql_ID,
trx.trx_query AS request_command,
lw.blocking_trx_id AS blocking_ID,
 trx1.trx_mysql_thread_id as blocking_mysql_ID,
trx1.trx_query AS blocking_command,
lo.lock_index AS lock_index
FROM
information_schema.innodb_lock_waits lw
INNER JOIN information_schema.innodb_locks lo ON lw.requesting_trx_id = lo.lock_trx_id
INNER JOIN information_schema.innodb_locks lo1 ON lw.blocking_trx_id = lo1.lock_trx_id
INNER JOIN information_schema.innodb_trx trx ON lo.lock_trx_id = trx.trx_id
INNER JOIN information_schema.innodb_trx trx1 ON lo1.lock_trx_id = trx1.trx_id;

1: INNODB_LOCKS

2: INNODB_TRX

3: INNODB_LOCK_WAITS
三張表就一起實驗好了,都是關於鎖和事物的阻塞的。我們現在開兩個終端。
第一個終端開啟一個事物,進行更新:
root@localhost [(none)]>start transaction;
Query OK, 0 rows affected (0.00 sec)
root@localhost [(none)]>update qiandai.t1 set col_int_key=333 where pk=10;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

第二個終端直接也更新同一行數據:

update qiandai.t1 set col_int_key=222 where pk=10;

然后去查看三個表聯合查詢:

 
可以看得到,第二個更新是被阻塞的,因為第一個更新獲取到了排它鎖,所以第二個更新一致處於等待狀態,直到鎖等待時間超時:
SHOW VARIABLES LIKE '%LOCK_WAIT%';

 

上面可以查看到鎖等待的超時時間,INNODB默認五十秒。
看一下三個表官方給的解釋:


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM