21.9.5. Performance Schema Statement Event Tables

21.9.5.1. The events_statements_current Table
21.9.5.2. The events_statements_history Table
21.9.5.3. The events_statements_history_long Table

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 events
events_statements_history: The most recent statement events for each thread
events_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_xxx codes defined in the mysql_com.h header file and processed in sql/sql_parse.cc. Examples are COM_PING, COM_QUERY, and COM_QUIT. Instruments for commands have names that begin with statement/com, such as statement/com/Ping, statement/com/Query, and statement/com/Quit.
SQL statements are expressed as text, such as DELETE FROM t1 or SELECT * FROM t2. Instruments for SQL statements have names that begin with statement/sql, such as statement/sql/delete and statement/sql/select.

There are also special error-handling instruments:

statement/com/Error accounts 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/error accounts 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 * FROM is malformed, and the statement/sql/error instrument is used. By contrast, SELECT * parses but fails with a No tables used error. In this case, statement/sql/select is 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.