Skip navigation links
MySQL Performance Schema :: 7 Performance Schema Table Descriptions :: 7.2 Performance Schema Current-Events Table
7.3 Performance Schema History Tables »
Section Navigation      [Toggle]

7.2. Performance Schema Current-Events Table

There is a single table for current events. Its name matches the pattern '%CURRENT': 

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
    -> WHERE TABLE_SCHEMA = 'performance_schema'
    -> AND TABLE_NAME LIKE '%CURRENT';
+----------------------+
| TABLE_NAME           |
+----------------------+
| EVENTS_WAITS_CURRENT |
+----------------------+

The EVENTS_WAITS_CURRENT table contains a row per thread showing the current status of each thread's most recent monitored event. When nested events are implemented, it will be possible for a thread to have multiple events in progress simultaneously.

This table can be truncated with TRUNCATE TABLE.

Of the tables that contain event rows, EVENTS_WAITS_CURRENT is the most fundamental. Other tables that contain event rows are logically derived from the current events. For example, the history tables are collections of the most recent events, up to a fixed number of rows.

The EVENTS_WAITS_CURRENT table has these columns:

  • THREAD_ID, EVENT_ID

    The thread associated with the event and the event number. These two values taken together form a primary key that uniquely identifies the row. No two rows will have the same pair of values.

  • EVENT_NAME

    The name of the instrument from which the event was collected. This is a SETUP_INSTRUMENTS.NAME value. Instrument names have multiple parts and form a hierarchy, as discussed in Section 5, “Performance Schema Event Instrument Naming Conventions”.

  • SOURCE

    The name of the source file containing the instrumented code that produced the event and the line number in the file at which the instrumentation occurs.

  • TIMER_START, TIMER_END, TIMER_WAIT

    Timing information for the event. The unit for these values is picoseconds (trillionths of a second). The TIMER_START and TIMER_END values indicate when event timing started and ended. TIMER_WAIT is the event elapsed time (duration).

    If an event has not finished, TIMER_END and TIMER_WAIT are NULL.

    If an event is produced from an instrument that has TIMED = NO, timing information is not collected, and TIMER_START, TIMER_END, and TIMER_WAIT are all NULL.

    For discussion of picoseconds as the unit for event times and factors that affect time values, see Section 4, “Performance Schema Event Timing”.

  • SPINS

    For a mutex, the number of spin rounds. If the value is NULL, the code does not use spin rounds or spinning is not instrumented.

  • OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE, OBJECT_INSTANCE_BEGIN

    These columns identify the object “being acted on.” What that means depends on the object type.

    For a synchronization object (cond, mutex, rwlock):

    • OBJECT_SCHEMA, OBJECT_NAME, and OBJECT_TYPE are NULL.

    • OBJECT_INSTANCE_BEGIN is the address of the synchronization object in memory.

    For a file I/O object:

    • OBJECT_SCHEMA is NULL.

    • OBJECT_NAME is the file name.

    • OBJECT_TYPE is FILE.

    • OBJECT_INSTANCE_BEGIN is an address in memory.

    An OBJECT_INSTANCE_BEGIN value itself has no meaning, except that different values indicate different objects. OBJECT_INSTANCE_BEGIN can be used for debugging. For example, it can be used with GROUP BY OBJECT_INSTANCE_BEGIN to see whether the load on 1,000 mutexes (that protect, say, 1,000 pages or blocks of data) is spread evenly or just hitting a few bottlenecks. This can help you correlate with other sources of information if you see the same object address in a log file or another debugging or performance tool.

  • NESTING_EVENT_ID

    Currently NULL. Nested events are not implemented.

  • OPERATION

    The type of operation performed, such as lock, read, or write.

  • NUMBER_OF_BYTES

    The number of bytes read or written by the operation.