Performance Schema Event Timing measure, which is not affected by changes in processor frequency, so using a timer which is not based on cycles is the best. The default timer for statements is  NANOSECOND . The extra “overhead”  compared to the  CYCLE  timer is not significant, because the overhead caused by calling a timer twice (once when the statement starts, once when it ends) is orders of magnitude less compared to the CPU time used to execute the statement itself. Using the  CYCLE  timer has no benefit here, only drawbacks. The precision offered by the cycle counter depends on processor speed. If the processor runs at 1 GHz (one billion cycles/second) or higher, the cycle counter delivers sub-nanosecond precision. Using the cycle counter is much cheaper than getting the actual time of day. For example, the standard  gettimeofday() function can take hundreds of cycles, which is an unacceptable overhead for data gathering that may occur thousands or millions of times per second. MySQL works with cycle counters on x386 (Windows, macOS, Linux, Solaris, and other Unix flavors), PowerPC, and IA-64. Rows in Performance Schema tables that store current events and historical events have three columns to represent timing information:  TIMER_START  and  TIMER_END  indicate when an event started and finished, and  TIMER_WAIT  indicates event duration. The  setup_instruments  table has an  ENABLED  column to indicate the instruments for which to collect events. The table also has a  TIMED  column to indicate which instruments are timed. If an instrument is not enabled, it produces no events. If an enabled instrument is not timed, events produced by the instrument have  NULL  for the  TIMER_START ,  TIMER_END , and  TIMER_WAIT  timer values. This in turn causes those values to be ignored when calculating aggregate time values in summary tables (sum, minimum, maximum, and average). Internally, times within events are stored in units given by the timer in effect when event timing begins. For display when events are retrieved from Performance Schema tables, times are shown in picoseconds (trillionths of a second) to normalize them to a standard unit, regardless of which timer is selected. The timer baseline (“time zero” ) occurs at Performance Schema initialization during server startup. TIMER_START  and  TIMER_END  values in events represent picoseconds since the baseline.  TIMER_WAIT values are durations in picoseconds. Picosecond values in events are approximate. Their accuracy is subject to the usual forms of error associated with conversion from one unit to another. If the  CYCLE  timer is used and the processor rate varies, there might be drift. For these reasons, it is not reasonable to look at the  TIMER_START  value for 4906 Performance Schema Timer Representation in Events Cycle counters also have disadvantages: •End users expect to see timings in wall-clock units, such as fractions of a second. Converting from cycles to fractions of seconds can be expensive. For this reason, the conversion is a quick and fairly rough multiplication operation. •Processor cycle rate might change, such as when a laptop goes into power-saving mode or when a CPU slows down to reduce heat generation. If a processor’s cycle rate fluctuates, conversion from cycles to real-time units is subject to error. •Cycle counters might be unreliable or unavailable depending on the processor or the operating system. For example, on Pentiums, the instruction is  RDTSC  (an assembly-language rather than a C instruction) and it is theoretically possible for the operating system to prevent user-mode programs from using it. •Some processor details related to out-of-order execution or multiprocessor synchronization might cause the counter to seem fast or slow by up to 1000 cycles.