Movatterモバイル変換

THREAD_ID,EVENT_ID

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

END_EVENT_ID

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

EVENT_NAME

The name of the instrument that produced the event. This is aNAME value from thesetup_instruments table. Instrument names may have multiple parts and form a hierarchy, as discussed inSection 25.6, “Performance Schema 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. 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_WAIT

Timing information for the event. The unit for these values is picoseconds (trillionths of a second). TheTIMER_START andTIMER_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 is the current timer value andTIMER_WAIT is the time elapsed so far (TIMER_END −TIMER_START).

If an event is produced from an instrument that hasTIMED = NO, timing information is not collected, andTIMER_START,TIMER_END, andTIMER_WAIT are allNULL.

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

SPINS

For a mutex, the number of spin rounds. If the value isNULL, 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):

For a file I/O object:

For a socket object:

For a table I/O object:

AnOBJECT_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 withGROUP 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.

INDEX_NAME

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

NESTING_EVENT_ID

TheEVENT_ID value of the event within which this event is nested.

NESTING_EVENT_TYPE

The nesting event type. The value isTRANSACTION,STATEMENT,STAGE, orWAIT.

OPERATION

The type of operation performed, such aslock,read, orwrite.

NUMBER_OF_BYTES

The number of bytes read or written by the operation. For table I/O waits (events for thewait/io/table/sql/handler instrument),NUMBER_OF_BYTES indicates the number of rows. If the value is greater than 1, the event is for a batch I/O operation. The following discussion describes the difference between exclusively single-row reporting and reporting that reflects batch I/O.

MySQL executes joins using a nested-loop implementation. The job of the Performance Schema instrumentation is to provide row count and accumulated execution time per table in the join. Assume a join query of the following form that is executed using a table join order oft1,t2,t3:

SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...

Table“fanout” is the increase or decrease in number of rows from adding a table during join processing. If the fanout for tablet3 is greater than 1, the majority of row-fetch operations are for that table. Suppose that the join accesses 10 rows fromt1, 20 rows fromt2 per row fromt1, and 30 rows fromt3 per row of tablet2. With single-row reporting, the total number of instrumented operations is:

10 + (10 * 20) + (10 * 20 * 30) = 6210

A significant reduction in the number of instrumented operations is achievable by aggregating them per scan (that is, per unique combination of rows fromt1 andt2). With batch I/O reporting, the Performance Schema produces an event for each scan of the innermost tablet3 rather than for each row, and the number of instrumented row operations reduces to:

10 + (10 * 20) + (10 * 20) = 410

That is a reduction of 93%, illustrating how the batch-reporting strategy significantly reduces Performance Schema overhead for table I/O by reducing the number of reporting calls. The tradeoff is lesser accuracy for event timing. Rather than time for an individual row operation as in per-row reporting, timing for batch I/O includes time spent for operations such as join buffering, aggregation, and returning rows to the client.

For batch I/O reporting to occur, these conditions must be true:

FLAGS

Reserved for future use.