的data_locks
表显示持有和请求的数据锁。该表的行有一个THREAD_ID
列表示拥有锁的会话的线程ID,以及EVENT_ID
列,指示导致锁定的性能模式事件。的元组(THREAD_ID
,EVENT_ID
)值隐式地标识其他Performance Schema表中的父事件:
类中的父等待事件
events_waits_
表xxx
中的父阶段事件
events_stages_
表xxx
类中的父语句事件
events_statements_
表xxx
类中的父事务事件
events_transactions_current
表格
要获取父事件的详细信息,请加入THREAD_ID
而且EVENT_ID
在适当的父事件表中具有类似名称的列。该关系基于嵌套的集合数据模型,因此连接有几个子句。所表示的父表和子表父
而且孩子
,则连接如下所示:
父母的地方。THREAD_ID= child.THREAD_ID /* 1 */ AND parent.EVENT_ID < child.EVENT_ID /* 2 */ AND ( child.EVENT_ID <= parent.END_EVENT_ID /* 3a */ OR parent.END_EVENT_ID IS NULL /* 3b */ )
连接的条件是:
父事件和子事件在同一个线程中。
子事件开始于父事件之后,因此
EVENT_ID
值大于父节点的值。父事件已经完成或仍在运行。
要查找锁信息,data_locks
包含子事件的表。
的data_locks
表只显示了现有的锁,所以这些考虑适用于包含父事件的表:
对于事务,唯一的选择是
events_transactions_current
.如果一个事务完成,它可能在事务历史表中,但是锁已经没有了。对于语句,这完全取决于获得锁的语句是否是已经完成的事务中的语句(使用
events_statements_history
)或者语句仍在运行(使用events_statements_current
).对于阶段,逻辑类似于语句;使用
events_stages_history
或events_stages_current
.对于等待,逻辑类似于语句;使用
events_waits_history
或events_waits_current
.然而,由于记录了太多的等待,导致锁的等待很可能已经从历史表中消失了。
等待、舞台和声明事件很快就会从历史中消失。如果一条很久以前执行的语句占用了一个锁,但它位于一个仍然打开的事务中,那么可能无法找到该语句,但可以找到该事务。
这就是为什么嵌套集数据模型更适合定位父事件。当中间节点已经从历史表中消失时,父/子关系中的链接(数据锁->父等待->父阶段->父事务)不能很好地工作。
下面的场景说明了如何找到被锁的语句的父事务:
会话:
[1]启动事务;SELECT * FROM t1 WHERE pk = 1;[3] SELECT 'Hello, world';
会话B:
选择……从performance_schema。events_transactions_current AS parent INNER JOIN performance_schema.data_locks AS child WHERE parent.THREAD_ID = child.THREAD_ID AND parent.EVENT_ID < child.EVENT_ID AND ( child.EVENT_ID <= parent.END_EVENT_ID OR parent.END_EVENT_ID IS NULL );
会话B的查询应该显示语句[2]拥有记录上的数据锁pk = 1
.
如果会话A执行了更多的语句,[2]将从历史表中淡出。
查询应该显示在[1]中开始的事务,而不管执行了多少语句、阶段或等待。
要查看更多数据,还可以使用events_
表(事务除外),假设没有其他查询在服务器中运行(因此保留历史)。xxx
_history_long