Obtaining Parent Event Information 27.19.2 Obtaining Parent Event Information The  data_locks  table shows data locks held and requested. Rows of this table have a  THREAD_ID column indicating the thread ID of the session that owns the lock, and an  EVENT_ID  column indicating the Performance Schema event that caused the lock. Tuples of ( THREAD_ID ,  EVENT_ID ) values implicitly identify a parent event in other Performance Schema tables: •The parent wait event in the  events_waits_ xxx  tables •The parent stage event in the  events_stages_ xxx  tables •The parent statement event in the  events_statements_ xxx  tables •The parent transaction event in the  events_transactions_current  table To obtain details about the parent event, join the  THREAD_ID  and  EVENT_ID  columns with the columns of like name in the appropriate parent event table. The relation is based on a nested set data model, so the join has several clauses. Given parent and child tables represented by  parent  and  child , respectively, the join looks like this: WHERE The condititions for the join are: 1. The parent and child events are in the same thread. 2. The child event begins after the parent event, so its  EVENT_ID  value is greater than that of the parent. 3. The parent event has either completed or is still running. To find lock information,  data_locks  is the table containing child events. The  data_locks  table shows only existing locks, so these considerations apply regarding which table contains the parent event: •For transactions, the only choice is  events_transactions_current . If a transaction is completed, it may be in the transaction history tables, but the locks are gone already. •For statements, it all depends on whether the statement that took a lock is a statement in a transaction that has already completed (use  events_statements_history ) or the statement is still running (use events_statements_current ). •For stages, the logic is similar to that for statements; use  events_stages_history  or events_stages_current . •For waits, the logic is similar to that for statements; use  events_waits_history  or events_waits_current . However, so many waits are recorded that the wait that caused a lock is most likely gone from the history tables already. Wait, stage, and statement events disappear quickly from the history. If a statement that executed a long time ago took a lock but is in a still-open transaction, it might not be possible to find the statement, but it is possible to find the transaction. 5127 parent.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 */ ) +--------------------------------+----------+