Chapter 8 Performance Schema Table Descriptions

HOST

The host name. This should be a literal name, or '%' to mean “any host.”

USER

The user name. This should be a literal name, or '%' to mean “any user.”

ROLE

Unused.

ENABLED

Whether to enable instrumentation for foreground threads matched by the row. The value is YES or NO.

This column was added in MySQL 5.7.6. For earlier versions in which it is not present, the Performance Schema enables instrumentation only for foreground threads matched by some row in the table; instrumentation is implicitly disabled for nonmatching threads.

HISTORY

Whether to log historical events for foreground threads matched by the row. The value is YES or NO.

This column was added in MySQL 5.7.8. For earlier versions in which it is not present, the Performance Schema logs historical events either for all threads or no threads, depending on which history consumers are enabled or disabled.

NAME

The consumer name.

ENABLED

Whether the consumer is enabled. The value is YES or NO. This column can be modified. If you disable a consumer, the server does not spend time adding event information to it.

NAME

The instrument name. Instrument names may have multiple parts and form a hierarchy, as discussed in Chapter 5, Performance Schema Instrument Naming Conventions. Events produced from execution of an instrument have an EVENT_NAME value that is taken from the instrument NAME value. (Events do not really have a “name,” but this provides a way to associate events with instruments.)

ENABLED

Whether the instrument is enabled. The value is YES or NO. This column can be modified. A disabled instrument produces no events.

TIMED

Whether the instrument is timed. This column can be modified.

For memory instruments, the TIMED column in setup_instruments is ignored because memory operations are not timed.

If an enabled instrument is not timed, the instrument code is enabled, but the timer is not. Events produced by the instrument have NULL for the TIMER_START, TIMER_END, and TIMER_WAIT timer values. This in turn causes those values to be ignored when calculating the sum, minimum, maximum, and average time values in summary tables.

OBJECT_TYPE

The type of object to instrument. The value is one of 'EVENT' (Event Scheduler event), 'FUNCTION' (stored function), 'PROCEDURE' (stored procedure), 'TABLE' (base table), or 'TRIGGER' (trigger). Before MySQL 5.7.2, the value is always 'TABLE'.

TABLE filtering affects table I/O events (wait/io/table/sql/handler instrument) and table lock events (wait/lock/table/sql/handler instrument).

OBJECT_SCHEMA

The schema that contains the object. This should be a literal name, or '%' to mean “any schema.”

OBJECT_NAME

The name of the instrumented object. This should be a literal name, or '%' to mean “any object.”

ENABLED

Whether events for the object are instrumented. The value is YES or NO. This column can be modified.

TIMED

Whether events for the object are timed. This column can be modified.

NAME

The type of instrument the timer is used for.

TIMER_NAME

The timer that applies to the instrument type. This column can be modified.

NAME

The instrument name associated with the condition.

OBJECT_INSTANCE_BEGIN

The address in memory of the instrumented condition.

FILE_NAME

The file name.

EVENT_NAME

The instrument name associated with the file.

OPEN_COUNT

The count of open handles on the file. If a file was opened and then closed, it was opened 1 time, but OPEN_COUNT will be 0. To list all the files currently opened by the server, use WHERE OPEN_COUNT > 0.

NAME

The instrument name associated with the mutex.

OBJECT_INSTANCE_BEGIN

The address in memory of the instrumented mutex.

LOCKED_BY_THREAD_ID

When a thread currently has a mutex locked, LOCKED_BY_THREAD_ID is the THREAD_ID of the locking thread, otherwise it is NULL.

The setup_instruments table lists the name of the instrumentation point, with the prefix wait/synch/mutex/.

When some code creates a mutex, a row is added to the mutex_instances table. The OBJECT_INSTANCE_BEGIN column is a property that uniquely identifies the mutex.

When a thread attempts to lock a mutex, the events_waits_current table shows a row for that thread, indicating that it is waiting on a mutex (in the EVENT_NAME column), and indicating which mutex is waited on (in the OBJECT_INSTANCE_BEGIN column).

When a thread succeeds in locking a mutex:

When a thread unlocks a mutex, mutex_instances shows that the mutex now has no owner (the THREAD_ID column is NULL).

When a mutex object is destroyed, the corresponding row is removed from mutex_instances.

events_waits_current, to see what mutex a thread is waiting for

mutex_instances, to see which other thread currently owns a mutex

NAME

The instrument name associated with the lock.

OBJECT_INSTANCE_BEGIN

The address in memory of the instrumented lock.

WRITE_LOCKED_BY_THREAD_ID

When a thread currently has an rwlock locked in exclusive (write) mode, WRITE_LOCKED_BY_THREAD_ID is the THREAD_ID of the locking thread, otherwise it is NULL.

READ_LOCKED_BY_COUNT

When a thread currently has an rwlock locked in shared (read) mode, READ_LOCKED_BY_COUNT is incremented by 1. This is a counter only, so it cannot be used directly to find which thread holds a read lock, but it can be used to see whether there is a read contention on an rwlock, and see how many readers are currently active.

events_waits_current, to see what rwlock a thread is waiting for

rwlock_instances, to see which other thread currently owns an rwlock

EVENT_NAME

The name of the wait/io/socket/* instrument that produced the event. This is a NAME value from the setup_instruments table. Instrument names may have multiple parts and form a hierarchy, as discussed in Chapter 5, Performance Schema Instrument Naming Conventions.

OBJECT_INSTANCE_BEGIN

This column uniquely identifies the socket. The value is the address of an object in memory.

THREAD_ID

The internal thread identifier assigned by the server. Each socket is managed by a single thread, so each socket can be mapped to a thread which can be mapped to a server process.

SOCKET_ID

The internal file handle assigned to the socket.

IP

The client IP address. The value may be either an IPv4 or IPv6 address, or blank to indicate a Unix socket file connection.

PORT

The TCP/IP port number, in the range from 0 to 65535.

STATE

The socket status, either IDLE or ACTIVE. Wait times for active sockets are tracked using the corresponding socket instrument. Wait times for idle sockets are tracked using the idle instrument.

A socket is idle if it is waiting for a request from the client. When a socket becomes idle, the event row in socket_instances that is tracking the socket switches from a status of ACTIVE to IDLE. The EVENT_NAME value remains wait/io/socket/*, but timing for the instrument is suspended. Instead, an event is generated in the events_waits_current table with an EVENT_NAME value of idle.

When the next request is received, the idle event terminates, the socket instance switches from IDLE to ACTIVE, and timing of the socket instrument resumes.

For the Unix domain listener socket (server_unix_socket), the port is 0, and the IP is ''.

For client connections via the Unix domain listener (client_connection), the port is 0, and the IP is ''.

For the TCP/IP server listener socket (server_tcpip_socket), the port is always the master port (for example, 3306), and the IP is always 0.0.0.0.

For client connections via the TCP/IP listener (client_connection), the port is whatever the server assigns, but never 0. The IP is the IP of the originating host (127.0.0.1 or ::1 for the local host)

THREAD_ID, EVENT_ID

The thread associated with the event and the thread current event number when the event starts. The THREAD_ID and EVENT_ID values taken together form a primary key that uniquely identifies the row. No two rows will have the same pair of values.

END_EVENT_ID

This column is set to NULL when the event starts and updated to the thread current event number when the event ends.

EVENT_NAME

The name of the instrument that produced the event. This is a NAME value from the setup_instruments table. Instrument names may have multiple parts and form a hierarchy, as discussed in Chapter 5, Performance Schema Instrument Naming Conventions.

SOURCE

The name of the source file containing the instrumented code that produced the event and the line number in the file at which the instrumentation occurs. This enables you to check the source to determine exactly what code is involved. For example, if a mutex or lock is being blocked, you can check the context in which this occurs.

TIMER_START, TIMER_END, TIMER_WAIT

Timing information for the event. The unit for these values is picoseconds (trillionths of a second). The TIMER_START and TIMER_END values indicate when event timing started and ended. TIMER_WAIT is the event elapsed time (duration).

If an event has not finished, TIMER_END and TIMER_WAIT are NULL before MySQL 5.7.8. As of 5.7.8, TIMER_END is the current timer value and TIMER_WAIT is the time elapsed so far (TIMER_END − TIMER_START).

If an event is produced from an instrument that has TIMED = NO, timing information is not collected, and TIMER_START, TIMER_END, and TIMER_WAIT are all NULL.

For discussion of picoseconds as the unit for event times and factors that affect time values, see Section 3.3.1, “Performance Schema Event Timing”.

SPINS

For a mutex, the number of spin rounds. If the value is NULL, the code does not use spin rounds or spinning is not instrumented.

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE, OBJECT_INSTANCE_BEGIN

These columns identify the object “being acted on.” What that means depends on the object type.

For a synchronization object (cond, mutex, rwlock):

For a file I/O object:

For a socket object:

For a table I/O object:

An OBJECT_INSTANCE_BEGIN value itself has no meaning, except that different values indicate different objects. OBJECT_INSTANCE_BEGIN can be used for debugging. For example, it can be used with GROUP BY OBJECT_INSTANCE_BEGIN to see whether the load on 1,000 mutexes (that protect, say, 1,000 pages or blocks of data) is spread evenly or just hitting a few bottlenecks. This can help you correlate with other sources of information if you see the same object address in a log file or another debugging or performance tool.

INDEX_NAME

The name of the index used. PRIMARY indicates the table primary index. NULL means that no index was used.

NESTING_EVENT_ID

The EVENT_ID value of the event within which this event is nested.

NESTING_EVENT_TYPE

The nesting event type. The value is TRANSACTION, STATEMENT, STAGE, or WAIT.

OPERATION

The type of operation performed, such as lock, read, or write.

NUMBER_OF_BYTES

The number of bytes read or written by the operation. For table I/O waits (events for the wait/io/table/sql/handler instrument), NUMBER_OF_BYTES is NULL before MySQL 5.7.5. For table I/O events as of 5.7.5, this column indicates the number of rows. If the value is greater than 1, the event is for a batch I/O operation. The following discussion describes the difference between exclusively single-row reporting and reporting that reflects batch I/O.

MySQL executes joins using a nested-loop implementation. The job of the Performance Schema instrumentation is to provide row count and accumulated execution time per table in the join. Assume a join query of the following form that is executed using a table join order of t1, t2, t3:

SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...

Table “fanout” is the increase or decrease in number of rows from adding a table during join processing. If the fanout for table t3 is greater than 1, the majority of row-fetch operations are for that table. Suppose that the join accesses 10 rows from t1, 20 rows from t2 per row from t1, and 30 rows from t3 per row of table t2. With single-row reporting, the total number of instrumented operations is:

10 + (10 * 20) + (10 * 20 * 30) = 6210

A significant reduction in the number of instrumented operations is achievable by aggregating them per scan (that is, per unique combination of rows from t1 and t2). With batch I/O reporting, the Performance Schema produces an event for each scan of the innermost table t3 rather than for each row, and the number of instrumented row operations reduces to:

10 + (10 * 20) + (10 * 20) = 410

That is a reduction of 93%, illustrating how the batch-reporting strategy significantly reduces Performance Schema overhead for table I/O by reducing the number of reporting calls. The tradeoff is lesser accuracy for event timing. Rather than time for an individual row operation as in per-row reporting, timing for batch I/O includes time spent for operations such as join buffering, aggregation, and returning rows to the client.

For batch I/O reporting to occur, these conditions must be true:

FLAGS

Reserved for future use.

THREAD_ID, EVENT_ID

The thread associated with the event and the thread current event number when the event starts. The THREAD_ID and EVENT_ID values taken together form a primary key that uniquely identifies the row. No two rows will have the same pair of values.

END_EVENT_ID

This column is set to NULL when the event starts and updated to the thread current event number when the event ends.

EVENT_NAME

The name of the instrument that produced the event. This is a NAME value from the setup_instruments table. Instrument names may have multiple parts and form a hierarchy, as discussed in Chapter 5, Performance Schema Instrument Naming Conventions.

SOURCE

The name of the source file containing the instrumented code that produced the event and the line number in the file at which the instrumentation occurs. This enables you to check the source to determine exactly what code is involved.

TIMER_START, TIMER_END, TIMER_WAIT

Timing information for the event. The unit for these values is picoseconds (trillionths of a second). The TIMER_START and TIMER_END values indicate when event timing started and ended. TIMER_WAIT is the event elapsed time (duration).

If an event has not finished, TIMER_END and TIMER_WAIT are NULL before MySQL 5.7.8. As of 5.7.8, TIMER_END is the current timer value and TIMER_WAIT is the time elapsed so far (TIMER_END − TIMER_START).

If an event is produced from an instrument that has TIMED = NO, timing information is not collected, and TIMER_START, TIMER_END, and TIMER_WAIT are all NULL.

For discussion of picoseconds as the unit for event times and factors that affect time values, see Section 3.3.1, “Performance Schema Event Timing”.

WORK_COMPLETED, WORK_ESTIMATED

These columns provide stage progress information, for instruments that have been implemented to produce such information. WORK_COMPLETED indicates how many work units have been completed for the stage, and WORK_ESTIMATED indicates how many work units are expected for the stage. For more information, see Stage Event Progress Information.

These columns were added in MySQL 5.7.5.

NESTING_EVENT_ID

The EVENT_ID value of the event within which this event is nested. The nesting event for a stage event is usually a statement event.

NESTING_EVENT_TYPE

The nesting event type. The value is TRANSACTION, STATEMENT, STAGE, or WAIT.

THREAD_ID, EVENT_ID

The thread associated with the event and the thread current event number when the event starts. The THREAD_ID and EVENT_ID values taken together form a primary key that uniquely identifies the row. No two rows will have the same pair of values.

END_EVENT_ID

This column is set to NULL when the event starts and updated to the thread current event number when the event ends.

EVENT_NAME

The name of the instrument from which the event was collected. This is a NAME value from the setup_instruments table. Instrument names may have multiple parts and form a hierarchy, as discussed in Chapter 5, Performance Schema Instrument Naming Conventions.

For SQL statements, the EVENT_NAME value initially is statement/com/Query until the statement is parsed, then changes to a more appropriate value, as described in Section 8.6, “Performance Schema Statement Event Tables”.

SOURCE

The name of the source file containing the instrumented code that produced the event and the line number in the file at which the instrumentation occurs. This enables you to check the source to determine exactly what code is involved.

TIMER_START, TIMER_END, TIMER_WAIT

Timing information for the event. The unit for these values is picoseconds (trillionths of a second). The TIMER_START and TIMER_END values indicate when event timing started and ended. TIMER_WAIT is the event elapsed time (duration).

If an event has not finished, TIMER_END and TIMER_WAIT are NULL before MySQL 5.7.8. As of 5.7.8, TIMER_END is the current timer value and TIMER_WAIT is the time elapsed so far (TIMER_END − TIMER_START).

If an event is produced from an instrument that has TIMED = NO, timing information is not collected, and TIMER_START, TIMER_END, and TIMER_WAIT are all NULL.

For discussion of picoseconds as the unit for event times and factors that affect time values, see Section 3.3.1, “Performance Schema Event Timing”.

LOCK_TIME

The time spent waiting for table locks. This value is computed in microseconds but normalized to picoseconds for easier comparison with other Performance Schema timers.

SQL_TEXT

The text of the SQL statement. For a command not associated with an SQL statement, the value is NULL.

As of MySQL 5.7.6, the maximum number of bytes to display can be changed by changing the performance_schema_max_sql_text_length system variable at server startup. Before 5.7.6, the maximum is fixed at 1024.

DIGEST

The statement digest MD5 value as a string of 32 hexadecimal characters, or NULL if the statement_digest consumer is no. For more information about statement digesting, see Performance Schema Statement Digests.

DIGEST_TEXT

The normalized statement digest text, or NULL if the statement_digest consumer is no. For more information about statement digesting, see Performance Schema Statement Digests.

The performance_schema_max_digest_length system variable determines the maximum number of bytes available for computing statement digests. However, the display length of statement digests may be longer than the available buffer size due to encoding of statement components such as keywords and literal values in digest buffer. Consequently, values selected from the DIGEST_TEXT column of statement event tables may appear to exceed the performance_schema_max_digest_length value.

This variable was added in MySQL 5.7.8. In MySQL 5.7.6 and 5.7.7, use max_digest_length instead. Before 5.7.6, the value cannot be changed.

CURRENT_SCHEMA

The default database for the statement, NULL if there is none.

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE

For nested statements (stored programs), these columns contain information about the parent statement. Otherwise they are NULL.

OBJECT_INSTANCE_BEGIN

This column identifies the statement. The value is the address of an object in memory.

MYSQL_ERRNO

The statement error number, from the statement diagnostics area.

RETURNED_SQLSTATE

The statement SQLSTATE value, from the statement diagnostics area.

MESSAGE_TEXT

The statement error message, from the statement diagnostics area.

ERRORS

Whether an error occurred for the statement. The value is 0 if the SQLSTATE value begins with 00 (completion) or 01 (warning). The value is 1 is the SQLSTATE value is anything else.

WARNINGS

The number of warnings, from the statement diagnostics area.

ROWS_AFFECTED

The number of rows affected by the statement. For a description of the meaning of “affected,” see mysql_affected_rows().

ROWS_SENT

The number of rows returned by the statement.

ROWS_EXAMINED

The number of rows read from storage engines during statement execution.

CREATED_TMP_DISK_TABLES

Like the Created_tmp_disk_tables status variable, but specific to the statement.

CREATED_TMP_TABLES

Like the Created_tmp_tables status variable, but specific to the statement.

SELECT_FULL_JOIN

Like the Select_full_join status variable, but specific to the statement.

SELECT_FULL_RANGE_JOIN

Like the Select_full_range_join status variable, but specific to the statement.

SELECT_RANGE

Like the Select_range status variable, but specific to the statement.

SELECT_RANGE_CHECK

Like the Select_range_check status variable, but specific to the statement.

SELECT_SCAN

Like the Select_scan status variable, but specific to the statement.

SORT_MERGE_PASSES

Like the Sort_merge_passes status variable, but specific to the statement.

SORT_RANGE

Like the Sort_range status variable, but specific to the statement.

SORT_ROWS

Like the Sort_rows status variable, but specific to the statement.

SORT_SCAN

Like the Sort_scan status variable, but specific to the statement.

NO_INDEX_USED

1 if the statement performed a table scan without using an index, 0 otherwise.

NO_GOOD_INDEX_USED

1 if the server found no good index to use for the statement, 0 otherwise. For additional information, see the description of the Extra column from EXPLAIN output for the Range checked for each record value in EXPLAIN Output Format.

NESTING_EVENT_ID, NESTING_EVENT_TYPE, NESTING_EVENT_LEVEL

Before MySQL 5.7.2, only NESTING_EVENT_ID and NESTING_EVENT_TYPE exist and are always NULL.

As of MySQL 5.7.2, all three columns exist and are used with other columns to provide information as follows for top-level (unnested) statements and nested statements (executed within a stored program).

For top level statements:

OBJECT_TYPE = NULL
OBJECT_SCHEMA = NULL
OBJECT_NAME = NULL
NESTING_EVENT_ID = NULL
NESTING_EVENT_TYPE = NULL
NESTING_LEVEL = 0

For nested statements:

OBJECT_TYPE = the parent statement object type
OBJECT_SCHEMA = the parent statement object schema
OBJECT_NAME = the parent statement object name
NESTING_EVENT_ID = the parent statement EVENT_ID
NESTING_EVENT_TYPE = 'STATEMENT'
NESTING_LEVEL = the parent statement NESTING_LEVEL plus one

The binary protocol. This is accessed through the MySQL C API and maps onto underlying server commands as shown in the following table.

The text protocol. This is accessed using SQL statements and maps onto underlying server commands as shown in the following table.

Statement preparation

A COM_STMT_PREPARE or SQLCOM_PREPARE command creates a prepared statement in the server. If the statement is successfully instrumented, a new row is added to the prepared_statements_instances table. If the statement cannot be instrumented, Performance_schema_prepared_statements_lost status variable is incremented.

Prepared statement execution

Execution of a COM_STMT_EXECUTE or SQLCOM_PREPARE command for an instrumented prepared statement instance updates the corresponding prepared_statements_instances table row.

Prepared statement deallocation

Execution of a COM_STMT_CLOSE or SQLCOM_DEALLOCATE_PREPARE command for an instrumented prepared statement instance removes the corresponding prepared_statements_instances table row. To avoid resource leaks, removal occurs even if the prepared statement instruments described previously are disabled.

OBJECT_INSTANCE_BEGIN

The address in memory of the instrumented prepared statement.

STATEMENT_ID

The internal statement ID assigned by the server. The text and binary protocols both use statement IDs.

STATEMENT_NAME

For the binary protocol, this column is NULL. For the text protocol, this column is the external statement name assigned by the user. For example, for the following SQL statement, the name of the prepared statement is stmt:

PREPARE stmt FROM 'SELECT 1';

SQL_TEXT

The prepared statement text, with ? placeholder markers.

OWNER_THREAD_ID, OWNER_EVENT_ID

These columns indicate the event that created the prepared statement.

OWNER_OBJECT_TYPE, OWNER_OBJECT_SCHEMA, OWNER_OBJECT_NAME

For a prepared statement created by a client session, these columns are NULL. For a prepared statement created by a stored program, these columns point to the stored program. A typical user error is forgetting to deallocate prepared statements. These columns can be used to find stored programs that leak prepared statements:

SELECT OWNER_OBJECT_TYPE, OWNER_OBJECT_SCHEMA, OWNER_OBJECT_NAME,
STATEMENT_NAME, SQL_TEXT
FROM performance_schema.prepared_statements_instances
WHERE OWNER_OBJECT_TYPE IS NOT NULL;

TIMER_PREPARE

The time spent executing the statement preparation itself.

COUNT_REPREPARE

The number of times the statement was reprepared internally (see Caching of Prepared Statements and Stored Programs). Timing statistics for repreparation are not available because it is counted as part of statement execution, not as a separate operation.

COUNT_EXECUTE, SUM_TIMER_EXECUTE, MIN_TIMER_EXECUTE, AVG_TIMER_EXECUTE, MAX_TIMER_EXECUTE

Aggregated statistics for executions of the prepared statement.

SUM_xxx

The remaining SUM_xxx columns are the same as for the statement summary tables (see Section 8.15.3, “Statement Summary Tables”).

THREAD_ID, EVENT_ID

The thread associated with the event and the thread current event number when the event starts. The THREAD_ID and EVENT_ID values taken together form a primary key that uniquely identifies the row. No two rows will have the same pair of values.

END_EVENT_ID

This column is set to NULL when the event starts and updated to the thread current event number when the event ends.

EVENT_NAME

The name of the instrument from which the event was collected. This is a NAME value from the setup_instruments table. Instrument names may have multiple parts and form a hierarchy, as discussed in Chapter 5, Performance Schema Instrument Naming Conventions.

STATE

The current transaction state. The value is ACTIVE (after START TRANSACTION or BEGIN), COMMITTED (after COMMIT), or ROLLED BACK (after ROLLBACK).

TRX_ID

Unused.

GTID

This column changed in MySQL 5.7.6.

XID

The XA transaction identifier. It has the format described in XA Transaction SQL Syntax. This column was removed in MySQL 5.7.7 and replaced with the XID_FORMAT_ID, XID_GTRID, and XID_BQUAL columns representing the components of XID values.

XID_FORMAT_ID, XID_GTRID, and XID_BQUAL

The components of the XA transaction identifier. They have the format described in XA Transaction SQL Syntax. These columns were added in MySQL 5.7.7 as replacements for the XID column.

XA_STATE

The state of the XA transaction. The value is ACTIVE (after XA START), IDLE (after XA END), PREPARED (after XA PREPARE), ROLLED BACK (after XA ROLLBACK), or COMMITTED (after XA COMMIT).

SOURCE

The name of the source file containing the instrumented code that produced the event and the line number in the file at which the instrumentation occurs. This enables you to check the source to determine exactly what code is involved.

TIMER_START, TIMER_END, TIMER_WAIT

Timing information for the event. The unit for these values is picoseconds (trillionths of a second). The TIMER_START and TIMER_END values indicate when event timing started and ended. TIMER_WAIT is the event elapsed time (duration).

If an event has not finished, TIMER_END and TIMER_WAIT are NULL before MySQL 5.7.8. As of 5.7.8, TIMER_END is the current timer value and TIMER_WAIT is the time elapsed so far (TIMER_END − TIMER_START).

If an event is produced from an instrument that has TIMED = NO, timing information is not collected, and TIMER_START, TIMER_END, and TIMER_WAIT are all NULL.

For discussion of picoseconds as the unit for event times and factors that affect time values, see Section 3.3.1, “Performance Schema Event Timing”.

ACCESS_MODE

The transaction access mode. The value is READ ONLY or READ WRITE.

ISOLATION_LEVEL

The transaction isolation level. The value is REPEATABLE READ, READ COMMITTED, READ UNCOMMITTED, or SERIALIZABLE.

AUTOCOMMIT

Whether autcommit mode was enabled when the transaction started.

NUMBER_OF_SAVEPOINTS, NUMBER_OF_ROLLBACK_TO_SAVEPOINT, NUMBER_OF_RELEASE_SAVEPOINT

The number of SAVEPOINT, ROLLBACK TO SAVEPOINT, and RELEASE SAVEPOINT statements issued during the transaction.

OBJECT_INSTANCE_BEGIN

Unused.

NESTING_EVENT_ID

The EVENT_ID value of the event within which this event is nested.

NESTING_EVENT_TYPE

The nesting event type. The value is TRANSACTION, STATEMENT, STAGE, or WAIT. (TRANSACTION will not appear because transactions cannot be nested.)

USER

The client user name for the connection. This is NULL for an internal thread, or for a user session that failed to authenticate.

HOST

The host from which the client connected. This is NULL for an internal thread, or for a user session that failed to authenticate.

CURRENT_CONNECTIONS

The current number of connections for the account.

TOTAL_CONNECTIONS

The total number of connections for the account.

HOST

The host from which the client connected. This is NULL for an internal thread, or for a user session that failed to authenticate.

CURRENT_CONNECTIONS

The current number of connections for the host.

TOTAL_CONNECTIONS

The total number of connections for the host.

USER

The client user name for the connection. This is NULL for an internal thread, or for a user session that failed to authenticate.

CURRENT_CONNECTIONS

The current number of connections for the user.

TOTAL_CONNECTIONS

The total number of connections for the user.

PROCESSLIST_ID

The connection identifier for the session.

ATTR_NAME

The attribute name.

ATTR_VALUE

The attribute value.

ORDINAL_POSITION

The order in which the attribute was added to the set of connection attributes.

PROCESSLIST_ID

The connection identifier for the session.

ATTR_NAME

The attribute name.

ATTR_VALUE

The attribute value.

ORDINAL_POSITION

The order in which the attribute was added to the set of connection attributes.

CHANNEL_NAME

The replication channel which this row is displaying. There is always a default replication channel, and more replication channels can be added. See Replication Channels for more information.

HOST

The master host that the slave is connected to. (CHANGE MASTER TO option: MASTER_HOST)

PORT

The port used to connect to the master. (CHANGE MASTER TO option: MASTER_PORT)

USER

The user name of the account used to connect to the master. (CHANGE MASTER TO option: MASTER_USER)

NETWORK_INTERFACE

The network interface that the slave is bound to, if any. (CHANGE MASTER TO option: MASTER_BIND)

AUTO_POSITION

1 if autopositioning is in use; otherwise 0. (CHANGE MASTER TO option: MASTER_AUTO_POSITION)

SSL_ALLOWED, SSL_CA_FILE, SSL_CA_PATH, SSL_CERTIFICATE, SSL_CIPHER, SSL_KEY, SSL_VERIFY_SERVER_CERTIFICATE, SSL_CRL_FILE, SSL_CRL_PATH

These columns show the SSL parameters used by the slave to connect to the master, if any.

SSL_ALLOWED has these values:

CHANGE MASTER TO options for the other SSL columns: MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_CIPHER, MASTER_SSL_CRL, MASTER_SSL_CRLPATH, MASTER_SSL_KEY, MASTER_SSL_VERIFY_SERVER_CERT.

Prior to MySQL 5.7.4, the value of SSL_CRL_PATH was not displayed correctly. (Bug #18174719)

CONNECTION_RETRY_INTERVAL

The number of seconds between connect retries. (CHANGE MASTER TO option: MASTER_CONNECT_RETRY)

CONNECTION_RETRY_COUNT

The number of times the slave can attempt to reconnect to the master in the event of a lost connection. (CHANGE MASTER TO option: MASTER_RETRY_COUNT)

HEARTBEAT_INTERVAL

The replication heartbeat interval on a slave, measured in seconds. Added in MySQL 5.7.5.

CHANNEL_NAME

The replication channel which this row is displaying. There is always a default replication channel, and more replication channels can be added. See Replication Channels for more information.

GROUP_NAME

This column is reserved for future use. Added in MySQL 5.7.6.

SOURCE_UUID

The server_uuid value from the master.

THREAD_ID

The I/O thread ID.

SERVICE_STATE

ON (thread exists and is active or idle), OFF (thread no longer exists), or CONNECTING (thread exists and is connecting to the master).

RECEIVED_TRANSACTION_SET

The set of global transaction IDs (GTIDs) corresponding to all transactions received by this slave. Empty if GTIDs are not in use. See GTID Sets for more information.

LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE

The error number and error message of the most recent error that caused the I/O thread to stop. An error number of 0 and message of the empty string mean “no error.” If the LAST_ERROR_MESSAGE value is not empty, the error values also appear in the slave's error log.

Issuing RESET MASTER or RESET SLAVE resets the values shown in these columns.

LAST_ERROR_TIMESTAMP

A timestamp in YYMMDD HH:MM:SS format that shows when the most recent I/O error took place.

LAST_HEARTBEAT_TIMESTAMP

A timestamp in YYMMDD HH:MM:SS format that shows when the most recent heartbeat signal was received by a replication slave. Added in MySQL 5.7.5.

COUNT_RECEIVED_HEARTBEATS

The total number of heartbeat signals that a replication slave received since the last time it was restarted or reset, or a CHANGE MASTER TO statement was issued. Added in MySQL 5.7.5.

CHANNEL_NAME

The replication channel which this row is displaying. There is always a default replication channel, and more replication channels can be added. See Replication Channels for more information.

DESIRED_DELAY

The number of seconds that the slave must lag the master. (CHANGE MASTER TO option: MASTER_DELAY)

CHANNEL_NAME

The replication channel which this row is displaying. There is always a default replication channel, and more replication channels can be added. See Replication Channels for more information.

SERVICE_STATE

Shows ON when the replication channel's applier threads are active or idle, OFF means that the applier threads are not active.

REMAINING_DELAY

If the slave is waiting for DESIRED_DELAY seconds to pass since the master applied an event, this field contains the number of delay seconds remaining. At other times, this field is NULL. (The DESIRED_DELAY value is stored in the replication_applier_configuration table.)

COUNT_TRANSACTIONS_RETRIES

Added in MySQL 5.7.5, shows the number of retries that were made because the slave SQL thread failed to apply a transaction.

CHANNEL_NAME

The replication channel which this row is displaying. There is always a default replication channel, and more replication channels can be added. See Replication Channels for more information.

THREAD_ID

The SQL/coordinator thread ID.

SERVICE_STATE

ON (thread exists and is active or idle) or OFF (thread no longer exists).

LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE

The error number and error message of the most recent error that caused the SQL/coordinator thread to stop. An error number of 0 and message of the empty string mean “no error.” If the LAST_ERROR_MESSAGE value is not empty, the error values also appear in the slave's error log.

Issuing RESET MASTER or RESET SLAVE resets the values shown in these columns.

All error codes and messages displayed in the LAST_ERROR_NUMBER and LAST_ERROR_MESSAGE columns correspond to error values listed in Server Error Codes and Messages.

LAST_ERROR_TIMESTAMP

A timestamp in YYMMDD HH:MM:SS format that shows when the most recent SQL/coordinator error occurred.

CHANNEL_NAME

The replication channel which this row is displaying. There is always a default replication channel, and more replication channels can be added. See Replication Channels for more information.

WORKER_ID

The worker identifier (same value as the id column in the mysql.slave_worker_info table). After STOP SLAVE, the THREAD_ID column becomes NULL, but the WORKER_ID value is preserved.

THREAD_ID

The worker thread ID.

SERVICE_STATE

ON (thread exists and is active or idle) or OFF (thread no longer exists).

LAST_SEEN_TRANSACTION

The transaction that the worker has last seen. The worker has not necessarily applied this transaction because it could still be in the process of doing so.

If the gtid_mode system variable value is OFF, this column is ANONYMOUS, indicating that transactions do not have global transaction identifiers (GTIDs) and are identified by file and position only.

If gtid_mode is ON, the column value is defined as follows:

LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE

The error number and error message of the most recent error that caused the worker thread to stop. An error number of 0 and message of the empty string mean “no error”. If the LAST_ERROR_MESSAGE value is not empty, the error values also appear in the slave's error log.

Issuing RESET MASTER or RESET SLAVE resets the values shown in these columns.

All error codes and messages displayed in the LAST_ERROR_NUMBER and LAST_ERROR_MESSAGE columns correspond to error values listed in Server Error Codes and Messages.

LAST_ERROR_TIMESTAMP

A timestamp in YYMMDD HH:MM:SS format that shows when the most recent worker error occurred.

CHANNEL_NAME

Name of the group replication channel.

MEMBER_ID

Identifier for this member; same as the server UUID.

MEMBER_HOST

Network address of this member (host name or IP address).

MEMBER_PORT

Port on which the server is listening.

MEMBER_STATE

Current state of this member; can be any one of the following:

CHANNEL_NAME

Name of the group replication channel

VIEW_ID

Current view identifier for this group.

MEMBER_ID

Identifier for this member; same as the server UUID.

COUNT_TRANSACTIONS_IN_QUEUE

Number of transactions pending certification

COUNT_TRANSACTIONS_CHECKED

Number of transactions already certified by this member.

COUNT_CONFLICTS_DETECTED

Number of transactions that were negatively certified.

COUNT_TRANSACTIONS_VALIDATING

Number of transactions with which one can execute certification with them, but have not been garbage collected.

TRANSACTIONS_COMMITTED_ALL_MEMBERS

Set of stable group transactions.

LAST_CONFLICT_FREE_TRANSACTION

Latest transaction certified without conflicts.

Locks that have been granted (shows which sessions own which current metadata locks)

Locks that have been requested but not yet granted (shows which sessions are waiting for which metadata locks).

Lock requests that have been killed by the deadlock detector or timed out and are waiting for the requesting session's lock request to be discarded

When a metadata lock is requested and obtained immediately, a row with a status of GRANTED is inserted.

When a metadata lock is requested and not obtained immediately, a row with a status of PENDING is inserted.

When a metadata lock previously requested is granted, its row status is updated to GRANTED.

When a metadata lock is released, its row is deleted.

When a pending lock request is canceled by the deadlock detector to break a deadlock (ER_LOCK_DEADLOCK), its row status is updated from PENDING to VICTIM.

When a pending lock request times out (ER_LOCK_WAIT_TIMEOUT), its row status is updated from PENDING to TIMEOUT.

When granted lock or pending lock request is killed, its row status is updated from GRANTED or PENDING to KILLED.

The VICTIM, TIMEOUT, and KILLED status values are brief and signify that the lock row is about to be deleted.

The PRE_ACQUIRE_NOTIFY and POST_RELEASE_NOTIFY status values are brief and signify that the metadata locking subsubsystem is notifying interested storage engines while entering lock acquisition or leaving lock release operations. These status values were added in MySQL 5.7.11.

OBJECT_TYPE

The type of lock used in the metadata lock subsystem: The value is one of GLOBAL, SCHEMA, TABLE, FUNCTION, PROCEDURE, TRIGGER (currently unused), EVENT, COMMIT, USER LEVEL LOCK, TABLESPACE, or LOCKING SERVICE.

A value of USER LEVEL LOCK indicates a lock acquired with GET_LOCK(). A value of LOCKING SERVICE indicates a lock acquired using the locking service described in The Locking Service.

OBJECT_SCHEMA

The schema that contains the object.

OBJECT_NAME

The name of the instrumented object.

OBJECT_INSTANCE_BEGIN

The address in memory of the instrumented object.

LOCK_TYPE

The lock type from the metadata lock subsystem. The value is one of INTENTION_EXCLUSIVE, SHARED, SHARED_HIGH_PRIO, SHARED_READ, SHARED_WRITE, SHARED_UPGRADABLE, SHARED_NO_WRITE, SHARED_NO_READ_WRITE, or EXCLUSIVE.

LOCK_DURATION

The lock duration from the metadata lock subsystem. The value is one of STATEMENT, TRANSACTION, or EXPLICIT. The STATEMENT and TRANSACTION values are for locks that are released at statement or transaction end, respectively. The EXPLICIT value is for locks that survive statement or transaction end and are released explicitly, such as global locks acquired with FLUSH TABLES WITH READ LOCK.

LOCK_STATUS

The lock status from the metadata lock subsystem. The value is one of PENDING, GRANTED, VICTIM, TIMEOUT, KILLED, PRE_ACQUIRE_NOTIFY, or POST_RELEASE_NOTIFY. The Performance Schema assigns these values as described earlier in this section.

SOURCE

The name of the source file containing the instrumented code that produced the event and the line number in the file at which the instrumentation occurs. This enables you to check the source to determine exactly what code is involved.

OWNER_THREAD_ID

The thread requesting a metadata lock.

OWNER_EVENT_ID

The event requesting a metadata lock.

OBJECT_TYPE

The table opened by a table handle.

OBJECT_SCHEMA

The schema that contains the object.

OBJECT_NAME

The name of the instrumented object.

OBJECT_INSTANCE_BEGIN

The table handle address in memory.

OWNER_THREAD_ID

The thread owning the table handle.

OWNER_EVENT_ID

The event which caused the table handle to be opened.

INTERNAL_LOCK

The table lock used at the SQL level. The value is one of READ, READ WITH SHARED LOCKS, READ HIGH PRIORITY, READ NO INSERT, WRITE ALLOW WRITE, WRITE CONCURRENT INSERT, WRITE LOW PRIORITY, or WRITE. For information about these lock types, see the include/thr_lock.h source file.

EXTERNAL_LOCK

The table lock used at the storage engine level. The value is one of READ EXTERNAL or WRITE EXTERNAL.

events_waits_summary_global_by_event_name has an EVENT_NAME column. Each row summarizes events for a given event name. An instrument might be used to create multiple instances of the instrumented object. For example, if there is an instrument for a mutex that is created for each connection, there are as many instances as there are connections. The summary row for the instrument summarizes over all these instances.

events_waits_summary_by_instance has EVENT_NAME and OBJECT_INSTANCE_BEGIN columns. Each row summarizes events for a given event name and object. If an instrument is used to create multiple instances, each instance has a unique OBJECT_INSTANCE_BEGIN value, so these instances are summarized separately in this table.

events_waits_summary_by_thread_by_event_name has THREAD_ID and EVENT_NAME columns. Each row summarizes events for a given thread and event name.

COUNT_STAR

The number of summarized events. This value includes all events, whether timed or nontimed.

SUM_TIMER_WAIT

The total wait time of the summarized timed events. This value is calculated only for timed events because nontimed events have a wait time of NULL. The same is true for the other xxx_TIMER_WAIT values.

MIN_TIMER_WAIT

The minimum wait time of the summarized timed events.

AVG_TIMER_WAIT

The average wait time of the summarized timed events.

MAX_TIMER_WAIT

The maximum wait time of the summarized timed events.

events_stages_summary_by_thread_by_event_name has THREAD_ID and EVENT_NAME columns. Each row summarizes events for a given thread and event name.

events_stages_summary_global_by_event_name has an EVENT_NAME column. Each row summarizes events for a given event name.

events_statements_summary_by_digest has SCHEMA_NAME and DIGEST columns. Each row summarizes events for given schema/digest values. (The DIGEST_TEXT column contains the corresponding normalized statement digest text, but is neither a grouping nor summary column.)

The maximum number of rows in the table is autosized at server startup. To set this maximum explicitly, set the performance_schema_digests_size system variable at server startup.

events_statements_summary_by_program has OBJECT_TYPE, OBJECT_SCHEMA, and OBJECT_NAME columns. Each row summarizes events for a given stored program (stored procedure or function, trigger, or event).

events_statements_summary_by_thread_by_event_name has THREAD_ID and EVENT_NAME columns. Each row summarizes events for a given thread and event name.

events_statements_summary_global_by_event_name has an EVENT_NAME column. Each row summarizes events for a given event name.

prepared_statements_instances has an OBJECT_INSTANCE_BEGIN column. Each row summarizes events for a given prepared statement.

COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

These columns are analogous to the columns of the same names in the event wait summary tables (see Section 8.15.1, “Event Wait Summary Tables”), except that the statement summary tables aggregate events from events_statements_current rather than events_waits_current.

The prepared_statements_instances table does not have these columns.

SUM_xxx

The aggregate of the corresponding xxx column in the events_statements_current table. For example, the SUM_LOCK_TIME and SUM_ERRORS columns in statement summary tables are the aggregates of the LOCK_TIME and ERRORS columns in events_statements_current table.

FIRST_SEEN_TIMESTAMP, LAST_SEEN_TIMESTAMP

The times at which a statement with the given digest value were first seen and most recently seen.

COUNT_STATEMENTS, SUM_STATEMENTS_WAIT, MIN_STATEMENTS_WAIT, AVG_STATEMENTS_WAIT, MAX_STATEMENTS_WAIT

Statistics about nested statements invoked during stored program execution.

COUNT_EXECUTE, SUM_TIMER_EXECUTE, MIN_TIMER_EXECUTE, AVG_TIMER_EXECUTE, MAX_TIMER_EXECUTE

Aggregated statistics for executions of the prepared statement.

If a events_statements_summary_by_digest row already exists with the digest value for the statement that just completed, statistics for the statement are aggregated to that row. The LAST_SEEN column is updated to the current time.

If no row has the digest value for the statement that just completed, and the table is not full, a new row is created for the statement. The FIRST_SEEN and LAST_SEEN columns are initialized with the current time.

If no row has the statement digest value for the statement that just completed, and the table is full, the statistics for the statement that just completed are added to a special “catch-all” row with DIGEST = NULL, which is created if necessary. If the row is created, the FIRST_SEEN and LAST_SEEN columns are initialized with the current time. Otherwise, the LAST_SEEN column is updated with the current time.

A DIGEST = NULL row that has a COUNT_STAR value that represents 5% of all digests shows that the digest summary table is very representative; the other rows cover 95% of the statements seen.

A DIGEST = NULL row that has a COUNT_STAR value that represents 50% of all digests shows that the digest summary table is not very representative; the other rows cover only half the statements seen. Most likely the DBA should increase the maximum table size so that more of the rows counted in the DIGEST = NULL row would be counted using more specific rows instead. To do this, set the performance_schema_digests_size system variable to a larger value at server startup. The default size is 200.

A row is added for an object when it is first used in the server.

The row for an object is removed when the object is dropped.

Statistics are aggregated in the row for an object as it executes.

events_transactions_summary_by_account_by_event_name has USER, HOST, and EVENT_NAME columns. Each row summarizes events for a given account and event name.

events_transactions_summary_by_host_by_event_name has HOST and EVENT_NAME columns. Each row summarizes events for a given host and event name.

events_transactions_summary_by_thread_by_event_name has THREAD_ID and EVENT_NAME columns. Each row summarizes events for a given thread and event name.

events_transactions_summary_by_user_by_event_name has USER and EVENT_NAME columns. Each row summarizes events for a given user and event name.

events_transactions_summary_global_by_event_name has an EVENT_NAME column. Each row summarizes events for a given event name.

COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

These columns are analogous to the columns of the same names in the event wait summary tables (see Section 8.15.1, “Event Wait Summary Tables”), except that the transaction summary tables aggregate events from events_transactions_current rather than events_waits_current. These columns summarize read-write and read-only transactions.

COUNT_READ_WRITE, SUM_TIMER_READ_WRITE, MIN_TIMER_READ_WRITE, AVG_TIMER_READ_WRITE, MAX_TIMER_READ_WRITE

These are similar to the COUNT_STAR and xxx_TIMER_WAIT columns, but summarize read-write transactions only.

COUNT_READ_ONLY, SUM_TIMER_READ_ONLY, MIN_TIMER_READ_ONLY, AVG_TIMER_READ_ONLY, MAX_TIMER_READ_ONLY

These are similar to the COUNT_STAR and xxx_TIMER_WAIT columns, but summarize read-only transactions only.

file_summary_by_event_name has an EVENT_NAME column. Each row summarizes events for a given event name.

file_summary_by_instance has FILE_NAME, EVENT_NAME, and OBJECT_INSTANCE_BEGIN columns. Each row summarizes events for a given file and event name.

COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

These columns aggregate all I/O operations.

COUNT_READ, SUM_TIMER_READ, MIN_TIMER_READ, AVG_TIMER_READ, MAX_TIMER_READ, SUM_NUMBER_OF_BYTES_READ

These columns aggregate all read operations, including FGETS, FGETC, FREAD, and READ.

COUNT_WRITE, SUM_TIMER_WRITE, MIN_TIMER_WRITE, AVG_TIMER_WRITE, MAX_TIMER_WRITE, SUM_NUMBER_OF_BYTES_WRITE

These columns aggregate all write operations, including FPUTS, FPUTC, FPRINTF, VFPRINTF, FWRITE, and PWRITE.

COUNT_MISC, SUM_TIMER_MISC, MIN_TIMER_MISC, AVG_TIMER_MISC, MAX_TIMER_MISC

These columns aggregate all other I/O operations, including CREATE, DELETE, OPEN, CLOSE, STREAM_OPEN, STREAM_CLOSE, SEEK, TELL, FLUSH, STAT, FSTAT, CHSIZE, RENAME, and SYNC. There are no byte counts for these operations.

table_io_waits_summary_by_index_usage: Table I/O waits per index

table_io_waits_summary_by_table: Table I/O waits per table

table_lock_waits_summary_by_table: Table lock waits per table

events_waits_summary_by_account_by_event_name: Wait events summarized per account and event name

events_waits_summary_by_user_by_event_name: Wait events summarized per user name and event name

events_waits_summary_by_host_by_event_name: Wait events summarized per host name and event name

events_stages_summary_by_account_by_event_name: Stage events summarized per account and event name

events_stages_summary_by_user_by_event_name: Stage events summarized per user name and event name

events_stages_summary_by_host_by_event_name: Stage events summarized per host name and event name

events_statements_summary_by_account_by_event_name: Statement events summarized per account and event name

events_statements_summary_by_user_by_event_name: Statement events summarized per user name and event name

events_statements_summary_by_host_by_event_name: Statement events summarized per host name and event name

xxx_summary_by_thread_by_event_name tables are more detailed than connection summary tables

xxx_summary_global_by_event_name tables are less detailed than connection summary tables

For tables with _by_account in the name, the USER, HOST, and EVENT_NAME columns group events per account and event name.

For tables with _by_host in the name, the HOST and EVENT_NAME columns group events per host name and event name.

For tables with _by_user in the name, the USER and EVENT_NAME columns group events per user name and event name.

socket_summary_by_instance: Aggregate timer and byte count statistics generated by the wait/io/socket/* instruments for all socket I/O operations, per socket instance. When a connection terminates, the row in socket_summary_by_instance corresponding to it is deleted.

socket_summary_by_event_name: Aggregate timer and byte count statistics generated by the wait/io/socket/* instruments for all socket I/O operations, per socket instrument.

socket_summary_by_instance has an OBJECT_INSTANCE_BEGIN column. Each row summarizes events for a given object.

socket_summary_by_event_name has an EVENT_NAME column. Each row summarizes events for a given event name.

COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

These columns aggregate all operations.

COUNT_READ, SUM_TIMER_READ, MIN_TIMER_READ, AVG_TIMER_READ, MAX_TIMER_READ, SUM_NUMBER_OF_BYTES_READ

These columns aggregate all receive operations (RECV, RECVFROM, and RECVMSG).

COUNT_WRITE, SUM_TIMER_WRITE, MIN_TIMER_WRITE, AVG_TIMER_WRITE, MAX_TIMER_WRITE, SUM_NUMBER_OF_BYTES_WRITE

These columns aggregate all send operations (SEND, SENDTO, and SENDMSG).

COUNT_MISC, SUM_TIMER_MISC, MIN_TIMER_MISC, AVG_TIMER_MISC, MAX_TIMER_MISC

These columns aggregate all other socket operations, such as CONNECT, LISTEN, ACCEPT, CLOSE, and SHUTDOWN. There are no byte counts for these operations.

Type of memory used (various caches, internal buffers, and so forth)

Thread, account, user, host indirectly performing the memory operation

Memory sizes used

Operation counts

Low and high water marks

memory_summary_by_account_by_event_name has USER, HOST, and EVENT_NAME columns. Each row summarizes events for a given account.

memory_summary_by_host_by_event_name has HOST and EVENT_NAME columns. Each row summarizes events for a given host.

memory_summary_by_thread_by_event_name has THREAD_ID and EVENT_NAME columns. Each row summarizes events for a given thread and event name.

memory_summary_by_user_by_event_name has USER and EVENT_NAME columns. Each row summarizes events for a given user.

memory_summary_global_by_event_name has an EVENT_NAME column. Each row summarizes events for a given event name.

COUNT_ALLOC, COUNT_FREE

These columns aggregate the number of calls to malloc-like and free-like functions.

SUM_NUMBER_OF_BYTES_ALLOC, SUM_NUMBER_OF_BYTES_FREE

These columns indicate the aggregate size of allocated and freed memory blocks.

CURRENT_COUNT_USED

This column is the aggregate number of currently allocated blocks that have not been freed yet. This is a convenience column, equal to COUNT_ALLOC − COUNT_FREE.

CURRENT_NUMBER_OF_BYTES_USED

This column is the aggregate size of currently allocated memory blocks that have not been freed yet. This is a convenience column, equal to SUM_NUMBER_OF_BYTES_ALLOC − SUM_NUMBER_OF_BYTES_FREE.

LOW_COUNT_USED, HIGH_COUNT_USED

These columns are the low and high water marks corresponding to the CURRENT_COUNT_USED column.

LOW_NUMBER_OF_BYTES_USED, HIGH_NUMBER_OF_BYTES_USED

These columns are the low and high water marks corresponding to the CURRENT_NUMBER_OF_BYTES_USED column.

In general, truncation resets the baseline for statistics, but does not change the server state. That is, truncating a memory table does not free memory.

COUNT_ALLOC and COUNT_FREE are reset to a new baseline, by reducing each counter by the same value.

Likewise, SUM_NUMBER_OF_BYTES_ALLOC and SUM_NUMBER_OF_BYTES_FREE are reset to a new baseline.

LOW_COUNT_USED and HIGH_COUNT_USED are reset to CURRENT_COUNT_USED.

LOW_NUMBER_OF_BYTES_USED and HIGH_NUMBER_OF_BYTES_USED are reset to CURRENT_NUMBER_OF_BYTES_USED.

status_by_account has USER, HOST, and VARIABLE_NAME columns to summarize status variables by account.

status_by_host has HOST and VARIABLE_NAME columns to summarize status variables by the host from which clients connected.

status_by_user has USER and VARIABLE_NAME columns to summarize status variables by client user name.

VARIABLE_VALUE

The aggregated status variable value for active and terminated sessions.

status_by_account: Aggregates account status from terminated sessions to user and host status, then resets account status.

status_by_host: Resets aggregated host status from terminated sessions.

status_by_user: Resets aggregated user status from terminated sessions.

IP

The IP address of the client that connected to the server, expressed as a string.

HOST

The resolved DNS host name for that client IP, or NULL if the name is unknown.

HOST_VALIDATED

Whether the IP-to-host name-to-IP DNS resolution was performed successfully for the client IP. If HOST_VALIDATED is YES, the HOST column is used as the host name corresponding to the IP so that calls to DNS can be avoided. While HOST_VALIDATED is NO, DNS resolution is attempted again for each connect, until it eventually completes with either a valid result or a permanent error. This information enables the server to avoid caching bad or missing host names during temporary DNS failures, which would affect clients forever.

SUM_CONNECT_ERRORS

The number of connection errors that are deemed “blocking” (assessed against the max_connect_errors system variable). Only protocol handshake errors are counted, and only for hosts that passed validation (HOST_VALIDATED = YES).

COUNT_HOST_BLOCKED_ERRORS

The number of connections that were blocked because SUM_CONNECT_ERRORS exceeded the value of the max_connect_errors system variable.

COUNT_NAMEINFO_TRANSIENT_ERRORS

The number of transient errors during IP-to-host name DNS resolution.

COUNT_NAMEINFO_PERMANENT_ERRORS

The number of permanent errors during IP-to-host name DNS resolution.

COUNT_FORMAT_ERRORS

The number of host name format errors. MySQL does not perform matching of Host column values in the mysql.user table against host names for which one or more of the initial components of the name are entirely numeric, such as 1.2.example.com. The client IP address is used instead. For the rationale why this type of matching does not occur, see Specifying Account Names.

COUNT_ADDRINFO_TRANSIENT_ERRORS

The number of transient errors during host name-to-IP reverse DNS resolution.

COUNT_ADDRINFO_PERMANENT_ERRORS

The number of permanent errors during host name-to-IP reverse DNS resolution.

COUNT_FCRDNS_ERRORS

The number of forward-confirmed reverse DNS errors. These errors occur when IP-to-host name-to-IP DNS resolution produces an IP address that does not match the client originating IP address.

COUNT_HOST_ACL_ERRORS

The number of errors that occur because no user from the client host can possibly log in. In such cases, the server returns ER_HOST_NOT_PRIVILEGED and does not even ask for a user name or password.

COUNT_NO_AUTH_PLUGIN_ERRORS

The number of errors due to requests for an unavailable authentication plugin. A plugin can be unavailable if, for example, it was never loaded or a load attempt failed.

COUNT_AUTH_PLUGIN_ERRORS

The number of errors reported by authentication plugins.

An authentication plugin can report different error codes to indicate the root cause of a failure. Depending on the type of error, one of these columns is incremented: COUNT_AUTHENTICATION_ERRORS, COUNT_AUTH_PLUGIN_ERRORS, COUNT_HANDSHAKE_ERRORS. New return codes are an optional extension to the existing plugin API. Unknown or unexpected plugin errors are counted in the COUNT_AUTH_PLUGIN_ERRORS column.

COUNT_HANDSHAKE_ERRORS

The number of errors detected at the wire protocol level.

COUNT_PROXY_USER_ERRORS

The number of errors detected when a proxy user A is proxied to another user B who does not exist.

COUNT_PROXY_USER_ACL_ERRORS

The number of errors detected when a proxy user A is proxied to another user B who does exist but for whom A does not have the PROXY privilege.

COUNT_AUTHENTICATION_ERRORS

The number of errors caused by failed authentication.

COUNT_SSL_ERRORS

The number of errors due to SSL problems.

COUNT_MAX_USER_CONNECTIONS_ERRORS

The number of errors caused by exceeding per-user connection quotas. See Setting Account Resource Limits.

COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS

The number of errors caused by exceeding per-user connections-per-hour quotas. See Setting Account Resource Limits.

COUNT_DEFAULT_DATABASE_ERRORS

The number of errors related to the default database. For example, the database did not exist or the user had no privileges for accessing it.

COUNT_INIT_CONNECT_ERRORS

The number of errors caused by execution failures of statements in the init_connect system variable value.

COUNT_LOCAL_ERRORS

The number of errors local to the server implementation and not related to the network, authentication, or authorization. For example, out-of-memory conditions fall into this category.

COUNT_UNKNOWN_ERRORS

The number of other, unknown errors not accounted for by other columns in this table. This column is reserved for future use, in case new error conditions must be reported, and if preserving the backward compatibility and table structure of the host_cache table is required.

FIRST_SEEN

The timestamp of the first connection attempt seen from the client in the IP column.

LAST_SEEN

The timestamp of the last connection attempt seen from the client in the IP column.

FIRST_ERROR_SEEN

The timestamp of the first error seen from the client in the IP column.

LAST_ERROR_SEEN

The timestamp of the last error seen from the client in the IP column.

TIMER_NAME

The name by which to refer to the timer when configuring the setup_timers table.

TIMER_FREQUENCY

The number of timer units per second. For a cycle timer, the frequency is generally related to the CPU speed. For example, on a system with a 2.4GHz processor, the CYCLE may be close to 2400000000.

TIMER_RESOLUTION

Indicates the number of timer units by which timer values increase. If a timer has a resolution of 10, its value increases by 10 each time.

TIMER_OVERHEAD

The minimal number of cycles of overhead to obtain one timing with the given timer. The Performance Schema determines this value by invoking the timer 20 times during initialization and picking the smallest value. The total overhead really is twice this amount because the instrumentation invokes the timer at the start and end of each event. The timer code is called only for timed events, so this overhead does not apply for nontimed events.

Access to threads does not require a mutex and has minimal impact on server performance. INFORMATION_SCHEMA.PROCESSLIST and SHOW PROCESSLIST have negative performance consequences because they require a mutex.

threads provides additional information for each thread, such as whether it is a foreground or background thread, and the location within the server associated with the thread.

threads provides information about background threads, so it can be used to monitor activity the other thread information sources cannot.

You can enable or disable thread monitoring (that is, whether events executed by the thread are instrumented) and historical event logging. To control the initial INSTRUMENTED and HISTORY values for new foreground threads, use the setup_actors table. To control these aspects of existing threads, set the INSTRUMENTED and HISTORY columns of threads table rows. (For more information about the conditions under which thread monitoring and historical event logging occur, see the descriptions of the INSTRUMENTED and HISTORY columns.)

THREAD_ID

A unique thread identifier.

NAME

The name associated with the thread instrumentation code in the server. For example, thread/sql/one_connection corresponds to the thread function in the code responsible for handling a user connection, and thread/sql/main stands for the main() function of the server.

TYPE

The thread type, either FOREGROUND or BACKGROUND. User connection threads are foreground threads. Threads associated with internal server activity are background threads. Examples are internal InnoDB threads, “binlog dump” threads sending information to slaves, and slave I/O and SQL threads.

PROCESSLIST_ID

For threads that are displayed in the INFORMATION_SCHEMA.PROCESSLIST table, this is the same value displayed in the ID column of that table. It is also the value displayed in the Id column of SHOW PROCESSLIST output, and the value that CONNECTION_ID() would return within that thread.

For background threads (threads not associated with a user connection), PROCESSLIST_ID is NULL, so the values are not unique.

PROCESSLIST_USER

The user associated with a foreground thread, NULL for a background thread.

PROCESSLIST_HOST

The host name of the client associated with a foreground thread, NULL for a background thread.

Unlike the HOST column of the INFORMATION_SCHEMA PROCESSLIST table or the Host column of SHOW PROCESSLIST output, the PROCESSLIST_HOST column does not include the port number for TCP/IP connections. To obtain this information from the Performance Schema, enable the socket instrumentation (which is not enabled by default) and examine the socket_instances table:

mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'wait/io/socket%';
+----------------------------------------+---------+-------+
| NAME                                   | ENABLED | TIMED |
+----------------------------------------+---------+-------+
| wait/io/socket/sql/server_tcpip_socket | NO      | NO    |
| wait/io/socket/sql/server_unix_socket  | NO      | NO    |
| wait/io/socket/sql/client_connection   | NO      | NO    |
+----------------------------------------+---------+-------+
3 rows in set (0.01 sec)
mysql> UPDATE setup_instruments SET ENABLED='YES' WHERE NAME LIKE 'wait/io/socket%';
Query OK, 3 rows affected (0.00 sec)
Rows matched: 3  Changed: 3  Warnings: 0
mysql> SELECT * FROM socket_instances\G
*************************** 1. row ***************************
           EVENT_NAME: wait/io/socket/sql/client_connection
OBJECT_INSTANCE_BEGIN: 140612577298432
            THREAD_ID: 31
            SOCKET_ID: 53
                   IP: ::ffff:127.0.0.1
                 PORT: 55642
                STATE: ACTIVE
...

PROCESSLIST_DB

The default database for the thread, or NULL if there is none.

PROCESSLIST_COMMAND

For foreground threads, the type of command the thread is executing on behalf of the client, or Sleep if the session is idle. For descriptions of thread commands, see Examining Thread Information. The value of this column corresponds to the COM_xxx commands of the client/server protocol and Com_xxx status variables. See Server Status Variables

Background threads do not execute commands on behalf of clients, so this column may be NULL.

PROCESSLIST_TIME

The time in seconds that the thread has been in its current state.

PROCESSLIST_STATE

An action, event, or state that indicates what the thread is doing. For descriptions of PROCESSLIST_STATE values, see Examining Thread Information. If the value if NULL, the thread may correspond to an idle client session or the work it is doing is not instrumented with stages.

Most states correspond to very quick operations. If a thread stays in a given state for many seconds, there might be a problem that bears investigation.

PROCESSLIST_INFO

The statement the thread is executing, or NULL if it is not executing any statement. The statement might be the one sent to the server, or an innermost statement if the statement executes other statements. For example, if a CALL statement executes a stored procedure that is executing a SELECT statement, the PROCESSLIST_INFO value shows the SELECT statement.

PARENT_THREAD_ID

If this thread is a subthread (spawned by another thread), this is the THREAD_ID value of the spawning thread.

ROLE

Unused.

INSTRUMENTED

Whether events executed by the thread are instrumented. The value is YES or NO.

For monitoring of events executed by the thread to occur, these things must be true:

HISTORY

Whether to log historical events for the thread. The value is YES or NO.

For historical event logging for the thread to occur, these things must be true:

The HISTORY column was added in MySQL 5.7.8. For earlier versions in which it is not present, the Performance Schema logs historical events either for all threads or no threads, depending on which history consumers are enabled or disabled.

CONNECTION_TYPE

The protocol used to establish the connection, or NULL for background threads. Permitted values are TCP/IP (TCP/IP connection established without SSL), SSL/TLS (TCP/IP connection established with SSL), Socket (Unix socket file connection), Named Pipe (Windows named pipe connection), and Shared Memory (Windows shared memory connection).

This column was added in MySQL 5.7.8.

THREAD_OS_ID

The thread or task identifier as defined by the underlying operating system, if there is one:

For Windows, THREAD_OS_ID corresponds to the thread ID visible in Process Explorer (https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx).

For Linux, THREAD_OS_ID corresponds to the value of the gettid() function. This value is exposed, for example, using the perf or ps -L commands, or in the proc file system (/proc/[pid]/task/[tid]). For more information, see the perf-stat(1), ps(1), and proc(5) man pages.

This column was added in MySQL 5.7.9.