Performance Schema Wait Event Tables • OBJECT_TYPE  is  TABLE  for a persistent base table or  TEMPORARY TABLE  for a temporary table. • OBJECT_INSTANCE_BEGIN  is an address in memory. • INDEX_NAME • NESTING_EVENT_ID • NESTING_EVENT_TYPE • OPERATION • NUMBER_OF_BYTES 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. The name of the index used.  PRIMARY  indicates the table primary index.  NULL  means that no index was used. The  EVENT_ID  value of the event within which this event is nested. The nesting event type. The value is  TRANSACTION ,  STATEMENT ,  STAGE , or  WAIT . The type of operation performed, such as  lock ,  read , or  write . 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 : 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: 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: 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 10 + (10 * 20) + (10 * 20) = 410 10 + (10 * 20) + (10 * 20 * 30) = 6210 SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ... 4962