Performance Schema Statement Event Tables For additional information about configuring event collection, see Section 27.3, “Performance Schema Startup Configuration” , and Section 27.4, “Performance Schema Runtime Configuration” . Statement monitoring begins from the moment 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. Statements within stored programs are monitored like other statements. Statement Monitoring When the Performance Schema instruments a request (server command or SQL statement), it uses instrument names that proceed in stages from more general (or “abstract” ) to more specific until it arrives at a final instrument name. Final instrument names correspond to server commands and SQL statements: •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  and  COM_QUIT . Instruments for commands have names that begin with  statement/com , such as  statement/com/Ping  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 . Some final instrument names are specific to error handling: • 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. A request can be obtained from any of these sources: •As a command or statement request from a client, which sends the request as packets •As a statement string read from the relay log on a replica •As an event from the Event Scheduler The details for a request are not initially known and the Performance Schema proceeds from abstract to specific instrument names in a sequence that depends on the source of the request. For a request received from a client: 1. When the server detects a new packet at the socket level, a new statement is started with an abstract instrument name of  statement/abstract/new_packet . 2. When the server reads the packet number, it knows more about the type of request received, and the Performance Schema refines the instrument name. For example, if the request is a  COM_PING  packet, the instrument name becomes  statement/com/Ping  and that is the final name. If the request is 4972