Documentation Home
MySQL 5.6 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 29.4Mb
PDF (A4) - 29.5Mb
Man Pages (TGZ) - 190.2Kb
Man Pages (Zip) - 304.8Kb
Info (Gzip) - 2.8Mb
Info (Zip) - 2.8Mb
Excerpts from this Manual The events_waits_current Table

The events_waits_current table contains current wait events. The table stores one row per thread showing the current status of the thread's most recent monitored wait event, so there is no system variable for configuring the table size.

Of the tables that contain wait event rows, events_waits_current is the most fundamental. Other tables that contain wait event rows are logically derived from the current events. For example, the events_waits_history and events_waits_history_long tables are collections of the most recent wait events that have ended, up to a maximum number of rows per thread and globally across all threads, respectively.

For more information about the relationship between the three wait event tables, see Section 22.9, “Performance Schema Tables for Current and Historical Events”.

For information about configuring whether to collect wait events, see Section 22.12.4, “Performance Schema Wait Event Tables”.

The events_waits_current table has these columns:


    The thread associated with the event and the thread current event number when the event starts. The THREAD_ID and EVENT_ID values taken together uniquely identify the row. No two rows have the same pair of values.


    This column is set to NULL when the event starts and updated to the thread current event number when the event ends.


    The name of the instrument that produced the event. This is a NAME value from the setup_instruments table. Instrument names may have multiple parts and form a hierarchy, as discussed in Section 22.6, “Performance Schema Instrument Naming Conventions”.


    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. This enables you to check the source to determine exactly what code is involved. For example, if a mutex or lock is being blocked, you can check the context in which this occurs.


    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 before MySQL 5.6.26. As of 5.6.26, TIMER_END is the current timer value and TIMER_WAIT is the time elapsed so far (TIMER_ENDTIMER_START).

    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 22.4.1, “Performance Schema Event Timing”.


    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.


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

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


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

    For a file I/O object:


    • OBJECT_NAME is the file name.


    • OBJECT_INSTANCE_BEGIN is an address in memory.

    For a socket object:

    • OBJECT_NAME is the IP:PORT value for the socket.

    • OBJECT_INSTANCE_BEGIN is an address in memory.

    For a table I/O object:

    • OBJECT_SCHEMA is the name of the schema that contains the table.

    • OBJECT_NAME is the table name.

    • OBJECT_TYPE is TABLE for a persistent base table or TEMPORARY TABLE for a temporary table.

    • 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.


    The name of the index used. PRIMARY indicates the table primary index. NULL means that no index was used.


    The EVENT_ID value of the event within which this event is nested.


    The nesting event type. The value is STATEMENT, STAGE, or WAIT.


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


    The number of bytes read or written by the operation. For table I/O waits (events for the wait/io/table/sql/handler instrument), NUMBER_OF_BYTES is NULL.


    Reserved for future use.

TRUNCATE TABLE is permitted for the events_waits_current table. It removes the rows.