Performance Schema Lock Tables LOCK_DATA: supremum pseudo-record Unlike most Performance Schema data collection, there are no instruments for controlling whether data lock information is collected or system variables for controlling data lock table sizes. The Performance Schema collects information that is already available in the server, so there is no memory or CPU overhead to generate this information or need for parameters that control its collection. Use the  data_locks  table to help diagnose performance problems that occur during times of heavy concurrent load. For  InnoDB , see the discussion of this topic at Section 15.15.2, “InnoDB INFORMATION_SCHEMA Transaction and Locking Information” . The  data_locks  table has these columns: The storage engine that holds or requested the lock. • ENGINE • ENGINE_LOCK_ID • ENGINE_TRANSACTION_ID • THREAD_ID • EVENT_ID The ID of the lock held or requested by the storage engine. Tuples of ( ENGINE_LOCK_ID ,  ENGINE ) values are unique. Lock ID formats are internal and subject to change at any time. Applications should not rely on lock IDs having a particular format. The storage engine internal ID of the transaction that requested the lock. This can be considered the owner of the lock, although the lock might still be pending, not actually granted yet ( LOCK_STATUS=’WAITING’ ). If the transaction has not yet performed any write operation (is still considered read only), the column contains internal data that users should not try to interpret. Otherwise, the column is the transaction ID. For  InnoDB , to obtain details about the transaction, join this column with the  TRX_ID  column of the INFORMATION_SCHEMA INNODB_TRX  table. The thread ID of the session that created the lock. To obtain details about the thread, join this column with the  THREAD_ID  column of the Performance Schema  threads  table. THREAD_ID  can be used together with  EVENT_ID  to determine the event during which the lock data structure was created in memory. (This event might have occurred before this particular lock request occurred, if the data structure is used to store multiple locks.) 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 5023