contains current wait events, one row per thread showing the
current status of the thread's most recent monitored wait
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, up to a fixed
number of rows.
has these columns:
The thread associated with the event. The
EVENT_ID values taken together form a
primary key that uniquely identifies the row. No two rows
will have the same pair of values.
The thread current event number when the event starts.
The name of the instrument that produced the event. This
Instrument names have multiple parts and form a hierarchy,
as discussed in
Section 21.4, “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_END values indicate when event
timing started and ended.
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
TIMER_WAIT are all
For discussion of picoseconds as the unit for event times and factors that affect time values, see Section 184.108.40.206, “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_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
OBJECT_INSTANCE_BEGIN value itself
has no meaning, except that different values indicate
OBJECT_INSTANCE_BEGIN can be used for
debugging. For example, it can be used with
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 type of operation performed, such as
The number of bytes read or written by the operation.
Reserved for future use.