Restrictions on Performance Schema This is why the nested set data model works better for locating parent events. Following links in a parent/ child relationship (data lock -> parent wait -> parent stage -> parent transaction) does not work well when intermediate nodes are already gone from the history tables. The following scenario illustrates how to find the parent transaction of a statement in which a lock was taken: Session A: Session B: The query for session B should show statement [2] as owning a data lock on the record with  pk=1 . If session A executes more statements, [2] fades out of the history table. The query should show the transaction that started in [1], regardless of how many statements, stages, or waits were executed. To see more data, you can also use the  events_ xxx _history_long  tables, except for transactions, assuming no other query runs in the server (so that history is preserved). The Performance Schema avoids using mutexes to collect or produce data, so there are no guarantees of consistency and results can sometimes be incorrect. Event values in  performance_schema  tables are nondeterministic and nonrepeatable. If you save event information in another table, you should not assume that the original events remain available later. For example, if you select events from a  performance_schema  table into a temporary table, intending to join that table with the original table later, there might be no matches. mysqldump  and  BACKUP DATABASE  ignore tables in the  performance_schema  database. Tables in the  performance_schema  database cannot be locked with  LOCK TABLES , except the setup_ xxx  tables. Tables in the  performance_schema  database cannot be indexed. Tables in the  performance_schema  database are not replicated. The types of timers might vary per platform. The  performance_timers  table shows which event timers are available. If the values in this table for a given timer name are  NULL , that timer is not supported on your platform. 5128 27.20 Restrictions on Performance Schema [1] START TRANSACTION; [2] SELECT * FROM t1 WHERE pk = 1; [3] SELECT ’Hello, world’; SELECT ... FROM 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 );