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;
然后去查看三个表联合查询:
![](https://images2015.cnblogs.com/blog/695151/201609/695151-20160920005741762-26142469.png)
可以看得到,第二个更新是被阻塞的,因为第一个更新获取到了排它锁,所以第二个更新一致处于等待状态,直到锁等待时间超时:
SHOW VARIABLES LIKE '%LOCK_WAIT%';
上面可以查看到锁等待的超时时间,INNODB默认五十秒。
看一下三个表官方给的解释:
看一下三个表官方给的解释:
INNODB_LOCK_WAITS:https://dev.mysql.com/doc/refman/5.7/en/innodb-lock-waits-table.html
热衷于学习讨论MySQL和SQL Server,NoSQL等数据库技术,欢迎加入SQL优化群:659336691