Performance Schema Event Timing troubleshooting, and so forth. Put the statements for each monitoring configuration into their own file and specify the appropriate file as the  init_file  value when you start the server. 27.4.1 Performance Schema Event Timing Events are collected by means of instrumentation added to the server source code. Instruments time events, which is how the Performance Schema provides an idea of how long events take. It is also possible to configure instruments not to collect timing information. This section discusses the available timers and their characteristics, and how timing values are represented in events. Performance Schema Timers Performance Schema timers vary in precision and amount of overhead. To see what timers are available and their characteristics, check the  performance_timers  table: mysql>  SELECT * FROM performance_schema.performance_timers; +-------------+-----------------+------------------+----------------+ | TIMER_NAME | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD | +-------------+-----------------+------------------+----------------+ | CYCLE | 2389029850 | 1 | 72 | | NANOSECOND | 1000000000 | 1 | 112 | | MICROSECOND | 1000000 | 1 | 136 | | MILLISECOND | 1036 | 1 | 168 | +-------------+-----------------+------------------+----------------+ If the values associated with a given timer name are  NULL , that timer is not supported on your platform. The columns have these meanings: •The  TIMER_NAME  column shows the names of the available timers.  CYCLE  refers to the timer that is based on the CPU (processor) cycle counter. • TIMER_FREQUENCY  indicates the number of timer units per second. For a cycle timer, the frequency is generally related to the CPU speed. The value shown was obtained on a system with a 2.4GHz processor. The other timers are based on fixed fractions of seconds. • TIMER_RESOLUTION  indicates the number of timer units by which timer values increase at a time. If a timer has a resolution of 10, its value increases by 10 each time. • TIMER_OVERHEAD  is the minimal number of cycles of overhead to obtain one timing with the given timer. The overhead per event is twice the value displayed because the timer is invoked at the beginning and end of the event. The Performance Schema assigns timers as follows: •The wait timer uses  CYCLE . •The idle, stage, statement, and transaction timers use  NANOSECOND  on platforms where the NANOSECOND  timer is available,  MICROSECOND  otherwise. At server startup, the Performance Schema verifies that assumptions made at build time about timer assignments are correct, and displays a warning if a timer is not available. To time wait events, the most important criterion is to reduce overhead, at the possible expense of the timer accuracy, so using the  CYCLE  timer is the best. The time a statement (or stage) takes to execute is in general orders of magnitude larger than the time it takes to execute a single wait. To time statements, the most important criterion is to have an accurate 4905