堵塞MySQL的会话是如何被快速杀掉的

前言

查找Innodb里面的锁，可以通过information_schema库下相关事务表和锁相关信息表来查到，在8.0的环境下，通过sys库下的锁相关表查询。一键获取Mysql笔记

information_schema.innodb_trx
存储了当前正在执行的事务信息

information_schema.innodb_locks
记录了锁信息如果一个事务想要获取到某个锁但未获取到，则记录该锁信息如果一个事务获取到了某个锁，但是这个锁阻塞了别的事务，则记录该锁信息但是无法通过该表查询到谁被阻塞，谁持有未释放。

information_schema.innodb_lock_waits
表明每个阻塞的事务是因为获取不到哪个事务持有的锁而被阻塞

information_schema.processlist
连接信息表

performance_schema.events_statements_current
记录当前执行的sql

performance_schema.events_statements_history
记录执行过的sql

sys.innodb_lock_waits 表

locked_table : 哪张表出现的等待

waiting_trx_id: 等待的事务(与上个视图trx_id 对应)

waiting_pid : 等待的连接号(与上个视图trx_mysql_thread_id或processlist_id)

blocking_trx_id : 锁源的事务ID

blocking_pid : 锁源的连接号

单一的锁快速查找方法

通过information_schema库下的锁信息表查询

整个流程如下：

（1）首先查询是否有锁，根据锁查到被锁的trx_id

（2）根据被锁的trx_id可以查到锁源的trx_id

（3）根据锁源的trx_id查到trx_mysql_thread_id（即processlist_id）

（4）再根据trx_mysql_thread_id查到thread_id

（5）最后，用thread_id查找到锁源的sql

但是这种方法在mysql8.0已经被移除，介绍另外一张表

通过sys库下的锁信息表查询

注意： MySQL8.0删除了information_schema.innodb_locks，添加了performance_schema.data_locks，可以通过performance_schema.data_locks查看事务的锁情况，和MySQL5.7及之前不同，performance_schema.data_locks不但可以看到阻塞该事务的锁，还可以看到该事务所持有的锁，也就是说即使事务并未被阻塞，依然可以看到事务所持有的锁（不过，正如文中最后一段所说，performance_schema.data_locks并不总是能看到全部的锁）。表名的变化其实还反映了8.0的performance_schema.data_locks更为通用了，即使你使用InnoDB之外的存储引擎，你依然可以从performance_schema.data_locks看到事务的锁情况。

因此第一种方法并不适用于8.0

通过sys库查询流程如下和第一种方式的原理其实是一样的

锁源的事务trx_id -->pnformaction_schema.processlist表的连接id–>performance_schema.threads表的thread_id–>performance_schema.events_statements_current 或performance_schema.events_statements_history查看sql

需要注意的是如下的三个id其实是同一个id，我这里把他们同称为连接ID，因为是由CONNECTION_ID()函数返回的

information_schema.innodb_trx(trx_mysql_thread_id)

information_schema.processlist(id)

sys