?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默認五十秒。 看一下三個表官方給的解釋： 看一下三個表官方給的解釋： ? INNODB_LOCKS：https://dev.mysql.com/doc/refman/5.7/en/innodb-locks-table.html
INNODB_TRX：https://dev.mysql.com/doc/refman/5.7/en/innodb-trx-table.html INNODB_LOCK_WAITS：https://dev.mysql.com/doc/refman/5.7/en/innodb-lock-waits-table.html

?

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的information_schema系列八(事物，锁)的全部內容，希望文章能夠幫你解決所遇到的問題。

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