The MySQL performance schema is used to monitor the resource consumption and resource waiting of the MySQL server during a lower level of operation. It has the following characteristics:
a. Provides a method to check the internal execution of the server in real time while the database is running. The tables in the performance_schema database use the performance_schema storage engine. This database mainly focuses on performance-related data during database operation. Unlike information_schema, information_schema mainly focuses on metadata information during server operation.
b. performance_schema monitors the internal operation of the server by monitoring the events of the server. "Events" are anything done in the internal activities of the server and the corresponding time consumption. Use this information to determine where the related resources in the server are consumed? Generally speaking, the event can be a function call, waiting of the operating system, a stage of SQL statement execution (such as the parsing or sorting stage in the execution of a SQL statement), or the entire SQL statement and a collection of SQL statements. The collection of events can conveniently provide information about the synchronous call of resources such as disk files, table I/O, and table locks by the relevant storage engine in the server.
c. The events in performance_schema are different from the events written in the binary log (events describing data modification) and the events of the event scheduler (this is a stored program). The events in performance_schema record the consumption of certain resources, time-consuming, and the number of executions of these activities when the server performs certain activities.
d. Events in performance_schema are only recorded in the performance_schema of the local server. When the data in these tables under it changes, it will not be written to the binlog, nor will it be copied to other servers through the replication mechanism.
e. Information recorded in tables related to current active events, historical events and event summary. Can provide the number of executions and duration of an event. It can then be used to analyze the activities associated with a specific thread and a specific object (such as mutex or file).
f. The performance_schema storage engine uses the "detection points" in the server source code to collect event data. There is no related separate thread to detect the code of the performance_schema implementation mechanism itself, which is different from other functions (such as replication or event scheduler).
g. The collected event data is stored in a table in the performance_schema database. These tables can be queried using SELECT statements, or SQL statements can be used to update the table records in the performance_schema database (such as dynamically modifying the configuration tables at the beginning of setup_* of performance_schema, but please note: the configuration table changes will take effect immediately, which will affect Data collection) (You can also control which events are collected through SQL statements).
h. The data in the performance_schema table will not be persistently stored in the disk, but stored in the memory. Once the server restarts, these data will be lost (all data under the entire performance_schema including the configuration table).
i. Event monitoring functions are available in all platforms supported by MySQL, but the types of timers used to count event time overhead on different platforms may be different.
The performance_schema implementation mechanism follows the following design goals:
Enabling performance_schema will not cause the server's behavior to change. For example, it will not change the thread scheduling mechanism, and will not cause the query execution plan (such as EXPLAIN) to change.
After enabling performance_schema, the server will continue to monitor without interruption, with very little overhead. Will not cause the server to be unavailable.
No new keywords or sentences are added in the implementation mechanism, and the parser will not change.
Even if the performance_schema monitoring mechanism fails to monitor an event internally, it will not affect the normal operation of the server.
If you encounter other threads that are querying the event information when you start collecting event data, the query will give priority to the collection of event data, because the collection of event data is a continuous process, and the retrieval (query) of these event data Search only when you need to view it. It is also possible that some event data will never be retrieved.