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
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 Performance Schema Tables for Current and Historical Events.
For information about configuring whether to collect wait events, see Section 10.4, “Performance Schema Wait Event Tables”.
has these columns:
The thread associated with the event and the thread current event number when the event starts. The
EVENT_IDvalues taken together uniquely identify the row. No two rows have the same pair of values.
The name of the instrument that produced the event. This is a
NAMEvalue from the
setup_instrumentstable. Instrument names may have multiple parts and form a hierarchy, as discussed in Chapter 7, 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_ENDvalues indicate when event timing started and ended.
TIMER_WAITis the event elapsed time (duration).
If an event has not finished,
If an event is produced from an instrument that has
TIMED = NO, timing information is not collected, and
For discussion of picoseconds as the unit for event times and factors that affect time values, see Section 5.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 (
OBJECT_INSTANCE_BEGINis the address of the synchronization object in memory.
For a file I/O object:
OBJECT_NAMEis the file name.
OBJECT_INSTANCE_BEGINis an address in memory.
OBJECT_INSTANCE_BEGINvalue itself has no meaning, except that different values indicate different objects.
OBJECT_INSTANCE_BEGINcan be used for debugging. For example, it can be used with
GROUP BY OBJECT_INSTANCE_BEGINto 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 type of operation performed, such as
The number of bytes read or written by the operation.
Reserved for future use.