What is MySQL Performance Schema

MySQL Performance Schema is a function used to monitor the execution of MySQL Server at a lower level. The performance architecture has the following characteristics:

• Performance mode provides a way to check the internal execution of the server at runtime. It is implemented using  PERFORMANCE_SCHEMAstorage engines and performance_schemadatabases. Performance mode mainly focuses on performance data. This INFORMATION_SCHEMAis different from the one used to check metadata.

• The performance framework monitors server events. What is an "event", the server does need time and equipment so that timing information can be collected. Generally, the event can be a function call, waiting for the operating system, the stage of SQL statement execution (such as parsing or sorting), or the entire statement or statement group. Through event collection, you can access information about synchronous calls (such as mutex locks) files, table I/O, table locks, etc. of the server and multiple storage engines.

• Performance architecture events are different from events written to the server's binary log (description of data modification) and event scheduler events (a type of stored program).

• Performance architecture events are specific to a given instance of MySQL server. Performance schema tables are considered server-local, and changes to them will not be copied or written to the binary log.

• Current events as well as event history and summaries are available. This allows you to determine how many times and how long it takes to perform detection activities. Event information can be used to show the activity of a specific thread, or the activity associated with a specific object (such as a mutex or a file).

• The PERFORMANCE_SCHEMAstorage engine uses the source code of the server to collect event data "check points".

• The collected events are stored in performance_schemaa table in the database. You can SELECT use statements to query these tables like other tables.

• performance_schema By using SQL statements to update the tables in the database, you can dynamically modify the Performance Schema configuration. Configuration changes will immediately affect data collection.

• The tables in the performance architecture are in-memory tables that do not use persistent disk storage. The content is refilled from when the server is started, and discarded when the server is shut down.

• Monitoring can be performed on all platforms supported by MySQL.

  There may be some limitations: the type of timer may vary from platform to platform. Tools applicable to storage engines may not be implemented for all storage engines. The instrument maintenance of each third-party engine is the responsibility of the engine maintainer. See also  Section 22.19 "Restrictions on Performance Modes" .

• Data collection is achieved by modifying the server source code to add tools. Unlike other functions (such as replication or event scheduler), there is no separate thread associated with the performance architecture.

The performance architecture is designed to provide access to useful information about the server's execution while minimizing the impact on server performance. The implementation follows the following design goals:

• Activating the performance architecture will not cause any changes in server behavior. For example, it will not cause a change in thread scheduling, nor will it cause a change in the query execution plan (as shown  EXPLAIN).

• Except for the memory allocation that occurs during server startup, there are no other memory allocations. By using early allocation of fixed-size structures, there is no need to resize or re-allocate them, which is critical to achieving good runtime performance.

• Server monitoring is carried out continuously, with little overhead. Activating the performance architecture does not make the server unavailable.

• The parser remains unchanged. There are no new keywords or phrases.

• Even if the performance mode fails internally, the execution of the server code will proceed normally.

• If there is a choice between initially performing processing during event collection or later during event retrieval, priority is given to making the collection faster. This is because collection is in progress, and retrieval is on-demand, which may not happen at all.

• It is easy to add new detection points.

• Instrument versioning. If the implementation changes are detected, the previously detected code will continue to work. This benefits the developers of third-party plug-ins, because it is not necessary to upgrade every plug-in to keep up with the latest performance architecture changes.