- 21.9 Performance Schema Table Descriptions
- 21.9.1 Performance Schema Setup Tables
- 21.9.2 Performance Schema Instance Tables
- 21.9.3 Performance Schema Wait Event Tables
- 21.9.4 Performance Schema Stage Event Tables
- 21.9.5 Performance Schema Statement Event Tables
- 21.9.6 Performance Schema Connection Tables
- 21.9.7 Performance Schema Connection Attribute Tables
- 21.9.8 Performance Schema Summary Tables
- 21.9.9 Performance Schema Miscellaneous Tables
[+/-]
As of MySQL 5.6.3, the Performance Schema instruments statement execution. Statement events occur at a high level of the event hierarchy. Wait events nest within stage events, which nest within statement events.
These tables store statement events:
events_statements_current: Current statement eventsevents_statements_history: The most recent statement events for each threadevents_statements_history_long: The most recent statement events overall
Statement monitoring begins from the moment when the server sees that activity is requested on a thread, to the moment when all activity has ceased. Typically, this means from the time the server gets the first packet from the client to the time the server has finished sending the response. Monitoring occurs only for top-level statements. Statements within stored programs and subqueries are not seen separately.
A request from a client can be either a command or a SQL statement:
Server commands correspond to the
COM_defined in thexxxcodesmysql_com.hheader file and processed insql/sql_parse.cc. Examples areCOM_PING,COM_QUERY, andCOM_QUIT. Instruments for commands have names that begin withstatement/com, such asstatement/com/Ping,statement/com/Query, andstatement/com/Quit.SQL statements are expressed as text, such as
DELETE FROM t1orSELECT * FROM t2. Instruments for SQL statements have names that begin withstatement/sql, such asstatement/sql/deleteandstatement/sql/select.
There are also special error-handling instruments:
statement/com/Erroraccounts for messages received by the server that are out of band. It can be used to detect commands sent by clients that the server does not understand. This may be helpful for purposes such as identifying clients that are misconfigured or using a version of MySQL more recent than that of the server, or clients that are attempting to attack the server.statement/sql/erroraccounts for SQL statements that fail to parse. It can be used to detect malformed queries sent by clients. A query that fails to parse differs from a query that parses but fails due to an error during execution. For example,SELECT * FROMis malformed, and thestatement/sql/errorinstrument is used. By contrast,SELECT *parses but fails with aNo tables usederror. In this case,statement/sql/selectis used and the statement event contains information to indicate the nature of the error.
Details for a request are not initially known. For example,
because a SQL statement is sent as text inside a
COM_QUERY packet, the proper
statement/sql/* instrument is not known at
the moment the request is received. The Performance Schema at
first instruments such a request using an event with an
EVENT_NAME of
statement/com/Query. Then it changes the
EVENT_NAME value to either a valid
statement/sql/* name if the statement parses,
or to statement/sql/error if it does not.
User Comments
Add your own comment.