Performance Schema Event Filtering an event as an accurate measure of time elapsed since server startup. On the other hand, it is reasonable to use  TIMER_START  or  TIMER_WAIT  values in  ORDER BY  clauses to order events by start time or duration. The choice of picoseconds in events rather than a value such as microseconds has a performance basis. One implementation goal was to show results in a uniform time unit, regardless of the timer. In an ideal world this time unit would look like a wall-clock unit and be reasonably precise; in other words, microseconds. But to convert cycles or nanoseconds to microseconds, it would be necessary to perform a division for every instrumentation. Division is expensive on many platforms. Multiplication is not expensive, so that is what is used. Therefore, the time unit is an integer multiple of the highest possible TIMER_FREQUENCY  value, using a multiplier large enough to ensure that there is no major precision loss. The result is that the time unit is “picoseconds.”  This precision is spurious, but the decision enables overhead to be minimized. While a wait, stage, statement, or transaction event is executing, the respective current-event tables display current-event timing information: events_waits_current events_stages_current events_statements_current events_transactions_current To make it possible to determine how long a not-yet-completed event has been running, the timer columns are set as follows: • TIMER_START  is populated. • TIMER_END  is populated with the current timer value. • TIMER_WAIT  is populated with the time elapsed so far ( TIMER_END − TIMER_START ). Events that have not yet completed have an  END_EVENT_ID  value of  NULL . To assess time elapsed so far for an event, use the  TIMER_WAIT  column. Therefore, to identify events that have not yet completed and have taken longer than  N  picoseconds thus far, monitoring applications can use this expression in queries: Event identification as just described assumes that the corresponding instruments have  ENABLED  and TIMED  set to  YES  and that the relevant consumers are enabled. WHERE END_EVENT_ID IS NULL AND TIMER_WAIT >  N 27.4.2 Performance Schema Event Filtering Events are processed in a producer/consumer fashion: •Instrumented code is the source for events and produces events to be collected. The setup_instruments  table lists the instruments for which events can be collected, whether they are enabled, and (for enabled instruments) whether to collect timing information: mysql>  SELECT NAME, ENABLED, TIMED FROM performance_schema.setup_instruments; +---------------------------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +---------------------------------------------------+---------+-------+ ... | wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES | | wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES | | wait/synch/mutex/sql/LOCK_lock_db | YES | YES | | wait/synch/mutex/sql/LOCK_manager | YES | YES | ... 4907