27.18 Performance Schema and Plugins ....................................................................................... 5123 27.19 Using the Performance Schema to Diagnose Problems ......................................................... 5123 27.19.1 Query Profiling Using Performance Schema .............................................................. 5125 27.19.2 Obtaining Parent Event Information ........................................................................... 5127 27.20 Restrictions on Performance Schema ................................................................................... 5128 The MySQL Performance Schema is a feature for monitoring MySQL Server execution at a low level. The Performance Schema has these characteristics: •The Performance Schema provides a way to inspect internal execution of the server at runtime. It is implemented using the  PERFORMANCE_SCHEMA  storage engine and the  performance_schema database. The Performance Schema focuses primarily on performance data. This differs from INFORMATION_SCHEMA , which serves for inspection of metadata. •The Performance Schema monitors server events. An “event”  is anything the server does that takes time and has been instrumented so that timing information can be collected. In general, an event could be a function call, a wait for the operating system, a stage of an SQL statement execution such as parsing or sorting, or an entire statement or group of statements. Event collection provides access to information about synchronization calls (such as for mutexes) file and table I/O, table locks, and so forth for the server and for several storage engines. •Performance Schema events are distinct from events written to the server’s binary log (which describe data modifications) and Event Scheduler events (which are a type of stored program). •Performance Schema events are specific to a given instance of the MySQL Server. Performance Schema tables are considered local to the server, and changes to them are not replicated or written to the binary log. •Current events are available, as well as event histories and summaries. This enables you to determine how many times instrumented activities were performed and how much time they took. Event information is available to show the activities of specific threads, or activity associated with particular objects such as a mutex or file. •The  PERFORMANCE_SCHEMA  storage engine collects event data using “instrumentation points”  in server source code. •Collected events are stored in tables in the  performance_schema  database. These tables can be queried using  SELECT  statements like other tables. •Performance Schema configuration can be modified dynamically by updating tables in the performance_schema  database through SQL statements. Configuration changes affect data collection immediately. •Tables in the Performance Schema are in-memory tables that use no persistent on-disk storage. The contents are repopulated beginning at server startup and discarded at server shutdown. •Monitoring is available on all platforms supported by MySQL. Some limitations might apply: The types of timers might vary per platform. Instruments that apply to storage engines might not be implemented for all storage engines. Instrumentation of each third- party engine is the responsibility of the engine maintainer. See also Section 27.20, “Restrictions on Performance Schema” . •Data collection is implemented by modifying the server source code to add instrumentation. There are no separate threads associated with the Performance Schema, unlike other features such as replication or the Event Scheduler. 4894