8.4.5.4 Audit Log File Formats (original) (raw)

The MySQL server calls the audit log plugin to write an audit record to its log file whenever an auditable event occurs. Typically the first audit record written after plugin startup contains the server description and startup options. Elements following that one represent events such as client connect and disconnect events, executed SQL statements, and so forth. Only top-level statements are logged, not statements within stored programs such as triggers or stored procedures. Contents of files referenced by statements such as LOAD DATA are not logged.

To select the log format that the audit log plugin uses to write its log file, set theaudit_log_format system variable at server startup. These formats are available:

By default, audit log file contents are written in new-style XML format, without compression or encryption.

If you change audit_log_format, it is recommended that you also changeaudit_log_file. For example, if you set audit_log_format toJSON, setaudit_log_file toaudit.json. Otherwise, newer log files will have a different format than older files, but they will all have the same base name with nothing to indicate when the format changed.

New-Style XML Audit Log File Format

Here is a sample log file in new-style XML format (audit_log_format=NEW), reformatted slightly for readability:

<?xml version="1.0" encoding="utf-8"?>
<AUDIT>
 <AUDIT_RECORD>
  <TIMESTAMP>2019-10-03T14:06:33 UTC</TIMESTAMP>
  <RECORD_ID>1_2019-10-03T14:06:33</RECORD_ID>
  <NAME>Audit</NAME>
  <SERVER_ID>1</SERVER_ID>
  <VERSION>1</VERSION>
  <STARTUP_OPTIONS>/usr/local/mysql/bin/mysqld
    --socket=/usr/local/mysql/mysql.sock
    --port=3306</STARTUP_OPTIONS>
  <OS_VERSION>i686-Linux</OS_VERSION>
  <MYSQL_VERSION>5.7.21-log</MYSQL_VERSION>
 </AUDIT_RECORD>
 <AUDIT_RECORD>
  <TIMESTAMP>2019-10-03T14:09:38 UTC</TIMESTAMP>
  <RECORD_ID>2_2019-10-03T14:06:33</RECORD_ID>
  <NAME>Connect</NAME>
  <CONNECTION_ID>5</CONNECTION_ID>
  <STATUS>0</STATUS>
  <STATUS_CODE>0</STATUS_CODE>
  <USER>root</USER>
  <OS_LOGIN/>
  <HOST>localhost</HOST>
  <IP>127.0.0.1</IP>
  <COMMAND_CLASS>connect</COMMAND_CLASS>
  <CONNECTION_TYPE>SSL/TLS</CONNECTION_TYPE>
  <CONNECTION_ATTRIBUTES>
   <ATTRIBUTE>
    <NAME>_pid</NAME>
    <VALUE>42794</VALUE>
   </ATTRIBUTE>
   ...
   <ATTRIBUTE>
    <NAME>program_name</NAME>
    <VALUE>mysqladmin</VALUE>
   </ATTRIBUTE>
  </CONNECTION_ATTRIBUTES>
  <PRIV_USER>root</PRIV_USER>
  <PROXY_USER/>
  <DB>test</DB>
 </AUDIT_RECORD>

...

 <AUDIT_RECORD>
  <TIMESTAMP>2019-10-03T14:09:38 UTC</TIMESTAMP>
  <RECORD_ID>6_2019-10-03T14:06:33</RECORD_ID>
  <NAME>Query</NAME>
  <CONNECTION_ID>5</CONNECTION_ID>
  <STATUS>0</STATUS>
  <STATUS_CODE>0</STATUS_CODE>
  <USER>root[root] @ localhost [127.0.0.1]</USER>
  <OS_LOGIN/>
  <HOST>localhost</HOST>
  <IP>127.0.0.1</IP>
  <COMMAND_CLASS>drop_table</COMMAND_CLASS>
  <SQLTEXT>DROP TABLE IF EXISTS t</SQLTEXT>
 </AUDIT_RECORD>

...

 <AUDIT_RECORD>
  <TIMESTAMP>2019-10-03T14:09:39 UTC</TIMESTAMP>
  <RECORD_ID>8_2019-10-03T14:06:33</RECORD_ID>
  <NAME>Quit</NAME>
  <CONNECTION_ID>5</CONNECTION_ID>
  <STATUS>0</STATUS>
  <STATUS_CODE>0</STATUS_CODE>
  <USER>root</USER>
  <OS_LOGIN/>
  <HOST>localhost</HOST>
  <IP>127.0.0.1</IP>
  <COMMAND_CLASS>connect</COMMAND_CLASS>
  <CONNECTION_TYPE>SSL/TLS</CONNECTION_TYPE>
 </AUDIT_RECORD>

...

 <AUDIT_RECORD>
  <TIMESTAMP>2019-10-03T14:09:43 UTC</TIMESTAMP>
  <RECORD_ID>11_2019-10-03T14:06:33</RECORD_ID>
  <NAME>Quit</NAME>
  <CONNECTION_ID>6</CONNECTION_ID>
  <STATUS>0</STATUS>
  <STATUS_CODE>0</STATUS_CODE>
  <USER>root</USER>
  <OS_LOGIN/>
  <HOST>localhost</HOST>
  <IP>127.0.0.1</IP>
  <COMMAND_CLASS>connect</COMMAND_CLASS>
  <CONNECTION_TYPE>SSL/TLS</CONNECTION_TYPE>
 </AUDIT_RECORD>
 <AUDIT_RECORD>
  <TIMESTAMP>2019-10-03T14:09:45 UTC</TIMESTAMP>
  <RECORD_ID>12_2019-10-03T14:06:33</RECORD_ID>
  <NAME>NoAudit</NAME>
  <SERVER_ID>1</SERVER_ID>
 </AUDIT_RECORD>
</AUDIT>

The audit log file is written as XML, using UTF-8 (up to 4 bytes per character). The root element is<AUDIT>. The root element contains<AUDIT_RECORD> elements, each of which provides information about an audited event. When the audit log plugin begins writing a new log file, it writes the XML declaration and opening <AUDIT> root element tag. When the plugin closes a log file, it writes the closing </AUDIT> root element tag. The closing tag is not present while the file is open.

Elements within <AUDIT_RECORD> elements have these characteristics:

#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]  

The following elements are mandatory in every<AUDIT_RECORD> element:

<NAME>Query</NAME>  

Some common <NAME> values:

Audit    When auditing starts, which may be server startup time  
Connect  When a client connects, also known as logging in  
Query    An SQL statement (executed directly)  
Prepare  Preparation of an SQL statement; usually followed by Execute  
Execute  Execution of an SQL statement; usually follows Prepare  
Shutdown Server shutdown  
Quit     When a client disconnects  
NoAudit  Auditing has been turned off  

The possible values are Audit,Binlog Dump, Change user, Close stmt,Connect Out,Connect, Create DB,Daemon, Debug,Delayed insert, Drop DB, Execute,Fetch, Field List,Init DB, Kill,Long Data, NoAudit,Ping, Prepare,Processlist, Query,Quit, Refresh,Register Slave, Reset stmt, Set option,Shutdown, Sleep,Statistics, Table Dump, TableDelete,TableInsert,TableRead,TableUpdate, Time.
Many of these values correspond to theCOM_ _`xxx`_ command values listed in themy_command.h header file. For example, Create DB and Change user correspond toCOM_CREATE_DB andCOM_CHANGE_USER, respectively.
Events having <NAME> values ofTable_`XXX`_ accompany Query events. For example, the following statement generates oneQuery event, twoTableRead events, and aTableInsert events:

INSERT INTO t3 SELECT t1.* FROM t1 JOIN t2;  

EachTable_`XXX`_ event contains <TABLE> and<DB> elements to identify the table to which the event refers and the database that contains the table.

<RECORD_ID>12_2019-10-03T14:06:33</RECORD_ID>  
<TIMESTAMP>2019-10-03T14:09:45 UTC</TIMESTAMP>  

The following elements are optional in<AUDIT_RECORD> elements. Many of them occur only with specific <NAME> element values.

<COMMAND_CLASS>drop_table</COMMAND_CLASS>  

The values correspond to thestatement/sql/_`xxx`_ command counters. For example,xxx isdrop_table andselect for DROP TABLE and SELECT statements, respectively. The following statement displays the possible names:

SELECT REPLACE(EVENT_NAME, 'statement/sql/', '') AS name  
FROM performance_schema.events_statements_summary_global_by_event_name  
WHERE EVENT_NAME LIKE 'statement/sql/%'  
ORDER BY name;  
<CONNECTION_ATTRIBUTES>  
 <ATTRIBUTE>  
  <NAME>_pid</NAME>  
  <VALUE>42794</VALUE>  
 </ATTRIBUTE>  
 <ATTRIBUTE>  
  <NAME>_os</NAME>  
  <VALUE>macos0.14</VALUE>  
 </ATTRIBUTE>  
 <ATTRIBUTE>  
  <NAME>_platform</NAME>  
  <VALUE>x86_64</VALUE>  
 </ATTRIBUTE>  
 <ATTRIBUTE>  
  <NAME>_client_version</NAME>  
  <VALUE>8.0.19</VALUE>  
 </ATTRIBUTE>  
 <ATTRIBUTE>  
  <NAME>_client_name</NAME>  
  <VALUE>libmysql</VALUE>  
 </ATTRIBUTE>  
 <ATTRIBUTE>  
  <NAME>program_name</NAME>  
  <VALUE>mysqladmin</VALUE>  
 </ATTRIBUTE>  
</CONNECTION_ATTRIBUTES>  

If no connection attributes are present in the event, none are logged and no<CONNECTION_ATTRIBUTES> element appears. This can occur if the connection attempt is unsuccessful, the client passes no attributes, or the connection occurs internally such as during server startup or when initiated by a plugin.

<CONNECTION_ID>127</CONNECTION_ID>  
<CONNECTION_TYPE>SSL/TLS</CONNECTION_TYPE>  
<DB>test</DB>  

For connect events, this element indicates the default database; the element is empty if there is no default database. For table-access events, the element indicates the database to which the accessed table belongs.

<HOST>localhost</HOST>  
<IP>127.0.0.1</IP>  
<MYSQL_VERSION>5.7.21-log</MYSQL_VERSION>  
<OS_LOGIN>jeffrey</OS_LOGIN>  
<OS_VERSION>x86_64-Linux</OS_VERSION>  
<PRIV_USER>jeffrey</PRIV_USER>  
<PROXY_USER>developer</PROXY_USER>  
<SERVER_ID>1</SERVER_ID>  
<SQLTEXT>DELETE FROM t1</SQLTEXT>  
<STARTUP_OPTIONS>/usr/local/mysql/bin/mysqld  
  --port=3306 --log_output=FILE</STARTUP_OPTIONS>  
<STATUS>1051</STATUS>  
<STATUS_CODE>0</STATUS_CODE>  
<TABLE>t3</TABLE>  
<USER>root[root] @ localhost [127.0.0.1]</USER>  
<VERSION>1</VERSION>  
Old-Style XML Audit Log File Format

Here is a sample log file in old-style XML format (audit_log_format=OLD), reformatted slightly for readability:

<?xml version="1.0" encoding="utf-8"?>
<AUDIT>
  <AUDIT_RECORD
    TIMESTAMP="2019-10-03T14:25:00 UTC"
    RECORD_ID="1_2019-10-03T14:25:00"
    NAME="Audit"
    SERVER_ID="1"
    VERSION="1"
    STARTUP_OPTIONS="--port=3306"
    OS_VERSION="i686-Linux"
    MYSQL_VERSION="5.7.21-log"/>
  <AUDIT_RECORD
    TIMESTAMP="2019-10-03T14:25:24 UTC"
    RECORD_ID="2_2019-10-03T14:25:00"
    NAME="Connect"
    CONNECTION_ID="4"
    STATUS="0"
    STATUS_CODE="0"
    USER="root"
    OS_LOGIN=""
    HOST="localhost"
    IP="127.0.0.1"
    COMMAND_CLASS="connect"
    CONNECTION_TYPE="SSL/TLS"
    PRIV_USER="root"
    PROXY_USER=""
    DB="test"/>

...

  <AUDIT_RECORD
    TIMESTAMP="2019-10-03T14:25:24 UTC"
    RECORD_ID="6_2019-10-03T14:25:00"
    NAME="Query"
    CONNECTION_ID="4"
    STATUS="0"
    STATUS_CODE="0"
    USER="root[root] @ localhost [127.0.0.1]"
    OS_LOGIN=""
    HOST="localhost"
    IP="127.0.0.1"
    COMMAND_CLASS="drop_table"
    SQLTEXT="DROP TABLE IF EXISTS t"/>

...

  <AUDIT_RECORD
    TIMESTAMP="2019-10-03T14:25:24 UTC"
    RECORD_ID="8_2019-10-03T14:25:00"
    NAME="Quit"
    CONNECTION_ID="4"
    STATUS="0"
    STATUS_CODE="0"
    USER="root"
    OS_LOGIN=""
    HOST="localhost"
    IP="127.0.0.1"
    COMMAND_CLASS="connect"
    CONNECTION_TYPE="SSL/TLS"/>
  <AUDIT_RECORD
    TIMESTAMP="2019-10-03T14:25:32 UTC"
    RECORD_ID="12_2019-10-03T14:25:00"
    NAME="NoAudit"
    SERVER_ID="1"/>
</AUDIT>

The audit log file is written as XML, using UTF-8 (up to 4 bytes per character). The root element is<AUDIT>. The root element contains<AUDIT_RECORD> elements, each of which provides information about an audited event. When the audit log plugin begins writing a new log file, it writes the XML declaration and opening <AUDIT> root element tag. When the plugin closes a log file, it writes the closing </AUDIT> root element tag. The closing tag is not present while the file is open.

Attributes of <AUDIT_RECORD> elements have these characteristics:

#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]  

The following attributes are mandatory in every<AUDIT_RECORD> element:

Audit    When auditing starts, which may be server startup time  
Connect  When a client connects, also known as logging in  
Query    An SQL statement (executed directly)  
Prepare  Preparation of an SQL statement; usually followed by Execute  
Execute  Execution of an SQL statement; usually follows Prepare  
Shutdown Server shutdown  
Quit     When a client disconnects  
NoAudit  Auditing has been turned off  

The possible values are Audit,Binlog Dump, Change user, Close stmt,Connect Out,Connect, Create DB,Daemon, Debug,Delayed insert, Drop DB, Execute,Fetch, Field List,Init DB, Kill,Long Data, NoAudit,Ping, Prepare,Processlist, Query,Quit, Refresh,Register Slave, Reset stmt, Set option,Shutdown, Sleep,Statistics, Table Dump, TableDelete,TableInsert,TableRead,TableUpdate, Time.
Many of these values correspond to theCOM_ _`xxx`_ command values listed in themy_command.h header file. For example, "Create DB" and"Change user" correspond toCOM_CREATE_DB andCOM_CHANGE_USER, respectively.
Events having NAME values ofTable_`XXX`_ accompany Query events. For example, the following statement generates oneQuery event, twoTableRead events, and aTableInsert events:

INSERT INTO t3 SELECT t1.* FROM t1 JOIN t2;  

EachTable_`XXX`_ event has TABLE andDB attributes to identify the table to which the event refers and the database that contains the table.
Connect events for old-style XML audit log format do not include connection attributes.

The following attributes are optional in<AUDIT_RECORD> elements. Many of them occur only for elements with specific values of theNAME attribute.

SELECT REPLACE(EVENT_NAME, 'statement/sql/', '') AS name  
FROM performance_schema.events_statements_summary_global_by_event_name  
WHERE EVENT_NAME LIKE 'statement/sql/%'  
ORDER BY name;  
JSON Audit Log File Format

For JSON-format audit logging (audit_log_format=JSON), the log file contents form a JSON array with each array element representing an audited event as a JSON hash of key-value pairs. Examples of complete event records appear later in this section. The following is an excerpt of partial events:

[
  {
    "timestamp": "2019-10-03 13:50:01",
    "id": 0,
    "class": "audit",
    "event": "startup",
    ...
  },
  {
    "timestamp": "2019-10-03 15:02:32",
    "id": 0,
    "class": "connection",
    "event": "connect",
    ...
  },
  ...
  {
    "timestamp": "2019-10-03 17:37:26",
    "id": 0,
    "class": "table_access",
    "event": "insert",
      ...
  }
  ...
]

The audit log file is written using UTF-8 (up to 4 bytes per character). When the audit log plugin begins writing a new log file, it writes the opening [ array marker. When the plugin closes a log file, it writes the closing] array marker. The closing marker is not present while the file is open.

Items within audit records have these characteristics:

JSON format is the only audit log file format that supports the optional query time and size statistics, which are available from MySQL 8.0.30. This data is available in the slow query log for qualifying queries, and in the context of the audit log it similarly helps to detect outliers for activity analysis.

To add the query statistics to the log file, you must set them up as a filter using theaudit_log_filter_set_filter() audit log function as the service element of the JSON filtering syntax. For instructions to do this, seeAdding Query Statistics for Outlier Detection. For thebytes_sent andbytes_received fields to be populated, the system variablelog_slow_extra must be set to ON.

The following examples show the JSON object formats for different event types (as indicated by theclass and event items), reformatted slightly for readability:

Auditing startup event:

{ "timestamp": "2019-10-03 14:21:56",
  "id": 0,
  "class": "audit",
  "event": "startup",
  "connection_id": 0,
  "startup_data": { "server_id": 1,
                    "os_version": "i686-Linux",
                    "mysql_version": "5.7.21-log",
                    "args": ["/usr/local/mysql/bin/mysqld",
                             "--loose-audit-log-format=JSON",
                             "--log-error=log.err",
                             "--pid-file=mysqld.pid",
                             "--port=3306" ] } }

When the audit log plugin starts as a result of server startup (as opposed to being enabled at runtime),connection_id is set to 0, andaccount and login are not present.

Auditing shutdown event:

{ "timestamp": "2019-10-03 14:28:20",
  "id": 3,
  "class": "audit",
  "event": "shutdown",
  "connection_id": 0,
  "shutdown_data": { "server_id": 1 } }

When the audit log plugin is uninstalled as a result of server shutdown (as opposed to being disabled at runtime),connection_id is set to 0, andaccount and login are not present.

Connect or change-user event:

{ "timestamp": "2019-10-03 14:23:18",
  "id": 1,
  "class": "connection",
  "event": "connect",
  "connection_id": 5,
  "account": { "user": "root", "host": "localhost" },
  "login": { "user": "root", "os": "", "ip": "::1", "proxy": "" },
  "connection_data": { "connection_type": "ssl",
                       "status": 0,
                       "db": "test",
                       "connection_attributes": {
                         "_pid": "43236",
                         ...
                         "program_name": "mysqladmin"
                       } }
}

Disconnect event:

{ "timestamp": "2019-10-03 14:24:45",
  "id": 3,
  "class": "connection",
  "event": "disconnect",
  "connection_id": 5,
  "account": { "user": "root", "host": "localhost" },
  "login": { "user": "root", "os": "", "ip": "::1", "proxy": "" },
  "connection_data": { "connection_type": "ssl" } }

Query event:

{ "timestamp": "2019-10-03 14:23:35",
  "id": 2,
  "class": "general",
  "event": "status",
  "connection_id": 5,
  "account": { "user": "root", "host": "localhost" },
  "login": { "user": "root", "os": "", "ip": "::1", "proxy": "" },
  "general_data": { "command": "Query",
                    "sql_command": "show_variables",
                    "query": "SHOW VARIABLES",
                    "status": 0 } }

Query event with optional query statistics for outlier detection:

{ "timestamp": "2022-01-28 13:09:30", 
  "id": 0, 
  "class": "general", 
  "event": "status", 
  "connection_id": 46, 
  "account": { "user": "user", "host": "localhost" }, 
  "login": { "user": "user", “os": "", “ip": "127.0.0.1", “proxy": "" }, 
  "general_data": { "command": "Query", 
                    "sql_command": "insert",
                "query": "INSERT INTO audit_table VALUES(4)",
                "status": 1146 }
  "query_statistics": { "query_time": 0.116250,
                        "bytes_sent": 18384,
                        "bytes_received": 78858,
                        "rows_sent": 3,
                        "rows_examined": 20878 } }

Table access event (read, delete, insert, update):

{ "timestamp": "2019-10-03 14:23:41",
  "id": 0,
  "class": "table_access",
  "event": "insert",
  "connection_id": 5,
  "account": { "user": "root", "host": "localhost" },
  "login": { "user": "root", "os": "", "ip": "127.0.0.1", "proxy": "" },
  "table_access_data": { "db": "test",
                         "table": "t1",
                         "query": "INSERT INTO t1 (i) VALUES(1),(2),(3)",
                         "sql_command": "insert" } }

The items in the following list appear at the top level of JSON-format audit records: Each item value is either a scalar or a JSON hash. For items that have a hash value, the description lists only the item names within that hash. For more complete descriptions of second-level hash items, see later in this section.

"account": { "user": "root", "host": "localhost" }  
"class": "connection"  

The following table shows the permitted combinations ofclass and event values.
Table 8.34 Audit Log Class and Event Combinations

Class Value Permitted Event Values
audit startup, shutdown
connection connect, change_user,disconnect
general status
table_access_data read, delete,insert, update
"connection_data": { "connection_type": "ssl",  
                     "status": 0,  
                     "db": "test" }  

As of MySQL 8.0.19, events with a class value of connection andevent value ofconnect may include aconnection_attributes item to display the connection attributes passed by the client at connect time. (For information about these attributes, which are also exposed in Performance Schema tables, seeSection 29.12.9, “Performance Schema Connection Attribute Tables”.)
The connection_attributes value is a hash that represents each attribute by its name and value.
Example:

"connection_attributes": {  
  "_pid": "43236",  
  "_os": "macos0.14",  
  "_platform": "x86_64",  
  "_client_version": "8.0.19",  
  "_client_name": "libmysql",  
  "program_name": "mysqladmin"  
}  

If no connection attributes are present in the event, none are logged and no connection_attributes item appears. This can occur if the connection attempt is unsuccessful, the client passes no attributes, or the connection occurs internally such as during server startup or when initiated by a plugin.

"connection_id": 5  
"event": "connect"  
"general_data": { "command": "Query",  
                  "sql_command": "show_variables",  
                  "query": "SHOW VARIABLES",  
                  "status": 0 }  
"id": 2  

For audit records that have the sametimestamp value, theirid values distinguish them and form a sequence. Within the audit log,timestamp/id pairs are unique. These pairs are bookmarks that identify event locations within the log.

"login": { "user": "root", "os": "", "ip": "::1", "proxy": "" }  
"query_statistics": { "query_time": 0.116250,  
                      "bytes_sent": 18384,  
                      "bytes_received": 78858,  
                      "rows_sent": 3,  
                      "rows_examined": 20878 }  
"shutdown_data": { "server_id": 1 }  
"startup_data": { "server_id": 1,  
                  "os_version": "i686-Linux",  
                  "mysql_version": "5.7.21-log",  
                  "args": ["/usr/local/mysql/bin/mysqld",  
                           "--loose-audit-log-format=JSON",  
                           "--log-error=log.err",  
                           "--pid-file=mysqld.pid",  
                           "--port=3306" ] }  
"table_access_data": { "db": "test",  
                       "table": "t1",  
                       "query": "INSERT INTO t1 (i) VALUES(1),(2),(3)",  
                       "sql_command": "insert" }  
"time" : 1618498687  

The time field occurs in JSON-format log files only if theaudit_log_format_unix_timestamp system variable is enabled.

"timestamp": "2019-10-03 13:50:01"  

For audit records that have the sametimestamp value, theirid values distinguish them and form a sequence. Within the audit log,timestamp/id pairs are unique. These pairs are bookmarks that identify event locations within the log.

These items appear within hash values associated with top-level items of JSON-format audit records:

"args": ["/usr/local/mysql/bin/mysqld",  
         "--loose-audit-log-format=JSON",  
         "--log-error=log.err",  
         "--pid-file=mysqld.pid",  
         "--port=3306" ]  
"bytes_received": 78858  
"bytes_sent": 18384  
"command": "Query"  
"connection_type": "tcp/tcp"  
"db": "test"  
"host": "localhost"  
"ip": "::1"  
"mysql_version": "5.7.21-log"  
"os": "jeffrey"  
"os_version": "i686-Linux"  
"proxy": "developer"  
"query": "DELETE FROM t1"  
"query_time": 0.116250  
"rows_examined": 20878  
"rows_sent": 3  
"server_id": 1  
"sql_command": "insert"  

The values correspond to thestatement/sql/_`xxx`_ command counters. For example,xxx isdrop_table andselect for DROP TABLE and SELECT statements, respectively. The following statement displays the possible names:

SELECT REPLACE(EVENT_NAME, 'statement/sql/', '') AS name  
FROM performance_schema.events_statements_summary_global_by_event_name  
WHERE EVENT_NAME LIKE 'statement/sql/%'  
ORDER BY name;  
"status": 1051  
"table": "t1"  
"user": "root"