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 nesting events are implemented, it
will be possible for a thread to have multiple events in
progress simultaneously, shown in different tables.
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_IDThe 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_NAMEThe name of the instrument from which the event was collected. This is a
setup_instruments.NAMEvalue. Instrument names have multiple parts and form a hierarchy, as discussed in Section 21.5, “Performance Schema Event Instrument Naming Conventions”.SOURCEThe 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.
TIMER_START,TIMER_END,TIMER_WAITTiming information for the event. The unit for these values is picoseconds (trillionths of a second). The
TIMER_STARTandTIMER_ENDvalues indicate when event timing started and ended.TIMER_WAITis the event elapsed time (duration).If an event has not finished,
TIMER_ENDandTIMER_WAITareNULL.If an event is produced from an instrument that has
TIMED = NO, timing information is not collected, andTIMER_START,TIMER_END, andTIMER_WAITare allNULL.For discussion of picoseconds as the unit for event times and factors that affect time values, see Section 21.4, “Performance Schema Event Timing”.
SPINSFor 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_BEGINThese 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, andOBJECT_TYPEareNULL.OBJECT_INSTANCE_BEGINis the address of the synchronization object in memory.
For a file I/O object:
OBJECT_SCHEMAisNULL.OBJECT_NAMEis the file name.OBJECT_TYPEisFILE.OBJECT_INSTANCE_BEGINis an address in memory.
An
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 withGROUP 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.NESTING_EVENT_IDCurrently
NULL.OPERATIONThe type of operation performed, such as
lock,read, orwrite.NUMBER_OF_BYTESThe number of bytes read or written by the operation.
FLAGSReserved for future use.