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

• INDEX_NAME 

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

• NESTING_EVENT_ID 

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

• NESTING_EVENT_TYPE 

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

• OPERATION 

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

• NUMBER_OF_BYTES 

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  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 of t1 , 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 table t3  is greater than 1, the majority of row-fetch operations are for that table. Suppose that the join accesses 10 rows from t1 , 20 rows from t2  per row from t1 , and 30 rows from t3  per row of table t2 . 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 from t1  and t2 ). With batch I/O reporting, the Performance Schema produces an event for each scan of the innermost table t3  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 

