7.1.10 Server Status Variables

Skip to Main Content

MySQL 8.4 Reference Manual Including MySQL NDB Cluster 8.4

7.1.10 Server Status Variables

The MySQL server maintains many status variables that provide information about its operation. You can view these variables and their values by using the SHOW [GLOBAL | SESSION] STATUS statement (see Section 15.7.7.37, “SHOW STATUS Statement”). The optional GLOBAL keyword aggregates the values over all connections, and SESSION shows the values for the current connection.

mysql> SHOW GLOBAL STATUS;
+-----------------------------------+------------+
| Variable_name                     | Value      |
+-----------------------------------+------------+
| Aborted_clients                   | 0          |
| Aborted_connects                  | 0          |
| Bytes_received                    | 155372598  |
| Bytes_sent                        | 1176560426 |
...
| Connections                       | 30023      |
| Created_tmp_disk_tables           | 0          |
| Created_tmp_files                 | 3          |
| Created_tmp_tables                | 2          |
...
| Threads_created                   | 217        |
| Threads_running                   | 88         |
| Uptime                            | 1389872    |
+-----------------------------------+------------+

Many status variables are reset to 0 by the FLUSH STATUS statement.

This section provides a description of each status variable. For a status variable summary, see Section 7.1.6, “Server Status Variable Reference”. For information about status variables specific to NDB Cluster, see Section 25.4.3.9.3, “NDB Cluster Status Variables”.

The status variables have the following meanings.

The number of connections that were aborted because the client died without closing the connection properly. See Section B.3.2.9, “Communication Errors and Aborted Connections”. - Aborted_connects

The number of failed attempts to connect to the MySQL server. See Section B.3.2.9, “Communication Errors and Aborted Connections”.

For additional connection-related information, check the Connection_errors_xxx status variables and the host_cache table. - Authentication_ldap_sasl_supported_methods

The authentication_ldap_sasl plugin that implements SASL LDAP authentication supports multiple authentication methods, but depending on host system configuration, they might not all be available. The Authentication_ldap_sasl_supported_methods variable provides discoverability for the supported methods. Its value is a string consisting of supported method names separated by spaces. Example: “SCRAM-SHA 1 SCRAM-SHA-256 GSSAPI“ - Binlog_cache_disk_use

The number of transactions that used the temporary binary log cache but that exceeded the value of binlog_cache_size and used a temporary file to store statements from the transaction.

The number of nontransactional statements that caused the binary log transaction cache to be written to disk is tracked separately in the Binlog_stmt_cache_disk_use status variable. - Acl_cache_items_count

The number of cached privilege objects. Each object is the privilege combination of a user and its active roles. - Binlog_cache_use

The number of transactions that used the binary log cache. - Binlog_stmt_cache_disk_use

The number of nontransaction statements that used the binary log statement cache but that exceeded the value of binlog_stmt_cache_size and used a temporary file to store those statements. - Binlog_stmt_cache_use

The number of nontransactional statements that used the binary log statement cache. - Bytes_received

The number of bytes received from all clients. - Bytes_sent

The number of bytes sent to all clients. - Caching_sha2_password_rsa_public_key

The public key used by the caching_sha2_password authentication plugin for RSA key pair-based password exchange. The value is nonempty only if the server successfully initializes the private and public keys in the files named by the caching_sha2_password_private_key_path and caching_sha2_password_public_key_path system variables. The value of Caching_sha2_password_rsa_public_key comes from the latter file. - Com_xxx

The Com_xxx statement counter variables indicate the number of times each xxx statement has been executed. There is one status variable for each type of statement. For example, Com_delete and Com_update count DELETE and UPDATE statements, respectively. Com_delete_multi and Com_update_multi are similar but apply to DELETE and UPDATE statements that use multiple-table syntax.

All Com_stmt_xxx variables are increased even if a prepared statement argument is unknown or an error occurred during execution. In other words, their values correspond to the number of requests issued, not to the number of requests successfully completed. For example, because status variables are initialized for each server startup and do not persist across restarts, the Com_restart and Com_shutdown variables that track RESTART and SHUTDOWN statements normally have a value of zero, but can be nonzero if RESTART or SHUTDOWN statements were executed but failed.

The Com_stmt_xxx status variables are as follows:

  • Com_stmt_prepare
  • Com_stmt_execute
  • Com_stmt_fetch
  • Com_stmt_send_long_data
  • Com_stmt_reset
  • Com_stmt_close

Those variables stand for prepared statement commands. Their names refer to the COM_xxx command set used in the network layer. In other words, their values increase whenever prepared statement API calls such as mysql_stmt_prepare(), mysql_stmt_execute(), and so forth are executed. However, Com_stmt_prepare, Com_stmt_execute and Com_stmt_close also increase for PREPARE, EXECUTE, or DEALLOCATE PREPARE, respectively. Additionally, the values of the older statement counter variables Com_prepare_sql, Com_execute_sql, and Com_dealloc_sql increase for the PREPARE, EXECUTE, and DEALLOCATE PREPARE statements. Com_stmt_fetch stands for the total number of network round-trips issued when fetching from cursors.

Com_stmt_reprepare indicates the number of times statements were automatically reprepared by the server, for example, after metadata changes to tables or views referred to by the statement. A reprepare operation increments Com_stmt_reprepare, and also Com_stmt_prepare.

Com_explain_other indicates the number of EXPLAIN FOR CONNECTION statements executed. See Section 10.8.4, “Obtaining Execution Plan Information for a Named Connection”.

Com_change_repl_filter indicates the number of CHANGE REPLICATION FILTER statements executed. - Compression

Whether the client connection uses compression in the client/server protocol.

This status variable is deprecated; expect it to be removed in a future version of MySQL. See Configuring Legacy Connection Compression. - Compression_algorithm

The name of the compression algorithm in use for the current connection to the server. The value can be any algorithm permitted in the value of the protocol_compression_algorithms system variable. For example, the value is uncompressed if the connection does not use compression, or zlib if the connection uses the zlib algorithm.

For more information, see Section 6.2.8, “Connection Compression Control”. - Compression_level

The compression level in use for the current connection to the server. The value is 6 for zlib connections (the default zlib algorithm compression level), 1 to 22 for zstd connections, and 0 for uncompressed connections.

For more information, see Section 6.2.8, “Connection Compression Control”. - Connection_errors_xxx

These variables provide information about errors that occur during the client connection process. They are global only and represent error counts aggregated across connections from all hosts. These variables track errors not accounted for by the host cache (see Section 7.1.12.3, “DNS Lookups and the Host Cache”), such as errors that are not associated with TCP connections, occur very early in the connection process (even before an IP address is known), or are not specific to any particular IP address (such as out-of-memory conditions).

The number of connection attempts (successful or not) to the MySQL server. - Created_tmp_disk_tables

The number of internal on-disk temporary tables created by the server while executing statements.

You can compare the number of internal on-disk temporary tables created to the total number of internal temporary tables created by comparing Created_tmp_disk_tables and Created_tmp_tables values.

Note

Due to a known limitation, Created_tmp_disk_tables does not count on-disk temporary tables created in memory-mapped files. By default, the TempTable storage engine overflow mechanism creates internal temporary tables in memory-mapped files. This behavior is controlled by the temptable_use_mmap variable.

See also Section 10.4.4, “Internal Temporary Table Use in MySQL”. - Created_tmp_files

How many temporary files mysqld has created. - Created_tmp_tables

The number of internal temporary tables created by the server while executing statements.

You can compare the number of internal on-disk temporary tables created to the total number of internal temporary tables created by comparing Created_tmp_disk_tables and Created_tmp_tables values.

See also Section 10.4.4, “Internal Temporary Table Use in MySQL”.

Each invocation of the SHOW STATUS statement uses an internal temporary table and increments the global Created_tmp_tables value. - Current_tls_ca

The active ssl_ca value in the SSL context that the server uses for new connections. This context value may differ from the current ssl_ca system variable value if the system variable has been changed but ALTER INSTANCE RELOAD TLS has not subsequently been executed to reconfigure the SSL context from the context-related system variable values and update the corresponding status variables. (This potential difference in values applies to each corresponding pair of context-related system and status variables. See Server-Side Runtime Configuration and Monitoring for Encrypted Connections.)

The Current_tls_xxx status variable values are also available through the Performance Schema tls_channel_status table. See Section 29.12.22.9, “The tls_channel_status Table”. - Current_tls_capath

The active ssl_capath value in the TLS context that the server uses for new connections. For notes about the relationship between this status variable and its corresponding system variable, see the description of Current_tls_ca. - Current_tls_cert

The active ssl_cert value in the TLS context that the server uses for new connections. For notes about the relationship between this status variable and its corresponding system variable, see the description of Current_tls_ca. - Current_tls_cipher

The active ssl_cipher value in the TLS context that the server uses for new connections. For notes about the relationship between this status variable and its corresponding system variable, see the description of Current_tls_ca. - Current_tls_ciphersuites

The active tls_ciphersuites value in the TLS context that the server uses for new connections. For notes about the relationship between this status variable and its corresponding system variable, see the description of Current_tls_ca. - Current_tls_crl

The active ssl_crl value in the TLS context that the server uses for new connections. For notes about the relationship between this status variable and its corresponding system variable, see the description of Current_tls_ca.

Note

When you reload the TLS context, OpenSSL reloads the file containing the CRL (certificate revocation list) as part of the process. If the CRL file is large, the server allocates a large chunk of memory (ten times the file size), which is doubled while the new instance is being loaded and the old one has not yet been released. The process resident memory is not immediately reduced after a large allocation is freed, so if you issue the ALTER INSTANCE RELOAD TLS statement repeatedly with a large CRL file, the process resident memory usage may grow as a result of this. - Current_tls_crlpath

The active ssl_crlpath value in the TLS context that the server uses for new connections. For notes about the relationship between this status variable and its corresponding system variable, see the description of Current_tls_ca. - Current_tls_key

The active ssl_key value in the TLS context that the server uses for new connections. For notes about the relationship between this status variable and its corresponding system variable, see the description of Current_tls_ca. - Current_tls_version

The active tls_version value in the TLS context that the server uses for new connections. For notes about the relationship between this status variable and its corresponding system variable, see the description of Current_tls_ca. - Delayed_errors

This status variable is deprecated (because DELAYED inserts are not supported); expect it to be removed in a future release. - Delayed_insert_threads

This status variable is deprecated (because DELAYED inserts are not supported); expect it to be removed in a future release. - Delayed_writes

This status variable is deprecated (because DELAYED inserts are not supported); expect it to be removed in a future release. - Deprecated_use_i_s_processlist_count

How many times the information_schema.processlist table has been accessed since the last restart. - Deprecated_use_i_s_processlist_last_timestamp

A timestamp indicating the last time the information_schema.processlist table has been accessed since the last restart. Shows microseconds since the Unix Epoch. - dragnet.Status

The result of the most recent assignment to the dragnet.log_error_filter_rules system variable, empty if no such assignment has occurred. - Error_log_buffered_bytes

The number of bytes currently used in the Performance Schema error_log table. It is possible for the value to decrease, for example, if a new event cannot fit until discarding an old event, but the new event is smaller than the old one. - Error_log_buffered_events

The number of events currently present in the Performance Schema error_log table. As with Error_log_buffered_bytes, it is possible for the value to decrease. - Error_log_expired_events

The number of events discarded from the Performance Schema error_log table to make room for new events. - Error_log_latest_write

The time of the last write to the Performance Schema error_log table. - Flush_commands

The number of times the server flushes tables, whether because a user executed a FLUSH TABLES statement or due to internal server operation. It is also incremented by receipt of a COM_REFRESH packet. This is in contrast to Com_flush, which indicates how many FLUSH statements have been executed, whether FLUSH TABLES, FLUSH LOGS, and so forth. - Global_connection_memory

The memory used by all user connections to the server. Memory used by system threads or by the MySQL root account is included in the total, but such threads or users are not subject to disconnection due to memory usage. This memory is not calculated unless global_connection_memory_tracking is enabled (disabled by default). The Performance Schema must also be enabled.

You can control (indirectly) the frequency with which this variable is updated by setting connection_memory_chunk_size. - Handler_commit

The number of internal COMMIT statements. - Handler_delete

The number of times that rows have been deleted from tables. - Handler_external_lock

The server increments this variable for each call to its external_lock() function, which generally occurs at the beginning and end of access to a table instance. There might be differences among storage engines. This variable can be used, for example, to discover for a statement that accesses a partitioned table how many partitions were pruned before locking occurred: Check how much the counter increased for the statement, subtract 2 (2 calls for the table itself), then divide by 2 to get the number of partitions locked. - Handler_mrr_init

The number of times the server uses a storage engine's own Multi-Range Read implementation for table access. - Handler_prepare

A counter for the prepare phase of two-phase commit operations. - Handler_read_first

The number of times the first entry in an index was read. If this value is high, it suggests that the server is doing a lot of full index scans (for example, SELECT col1 FROM foo, assuming that col1 is indexed). - Handler_read_key

The number of requests to read a row based on a key. If this value is high, it is a good indication that your tables are properly indexed for your queries. - Handler_read_last

The number of requests to read the last key in an index. With ORDER BY, the server issues a first-key request followed by several next-key requests, whereas with ORDER BY DESC, the server issues a last-key request followed by several previous-key requests. - Handler_read_next

The number of requests to read the next row in key order. This value is incremented if you are querying an index column with a range constraint or if you are doing an index scan. - Handler_read_prev

The number of requests to read the previous row in key order. This read method is mainly used to optimize ORDER BY ... DESC. - Handler_read_rnd

The number of requests to read a row based on a fixed position. This value is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan entire tables or you have joins that do not use keys properly. - Handler_read_rnd_next

The number of requests to read the next row in the data file. This value is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have. - Handler_rollback

The number of requests for a storage engine to perform a rollback operation. - Handler_savepoint

The number of requests for a storage engine to place a savepoint. - Handler_savepoint_rollback

The number of requests for a storage engine to roll back to a savepoint. - Handler_update

The number of requests to update a row in a table. - Handler_write

The number of requests to insert a row in a table. - Innodb_buffer_pool_dump_status

The progress of an operation to record the pages held in the InnoDB buffer pool, triggered by the setting of innodb_buffer_pool_dump_at_shutdown or innodb_buffer_pool_dump_now.

For related information and examples, see Section 17.8.3.6, “Saving and Restoring the Buffer Pool State”. - Innodb_buffer_pool_load_status

The progress of an operation to warm up the InnoDB buffer pool by reading in a set of pages corresponding to an earlier point in time, triggered by the setting of innodb_buffer_pool_load_at_startup or innodb_buffer_pool_load_now. If the operation introduces too much overhead, you can cancel it by setting innodb_buffer_pool_load_abort.

For related information and examples, see Section 17.8.3.6, “Saving and Restoring the Buffer Pool State”. - Innodb_buffer_pool_bytes_data

The total number of bytes in the InnoDB buffer pool containing data. The number includes both dirty and clean pages. For more accurate memory usage calculations than with Innodb_buffer_pool_pages_data, when compressed tables cause the buffer pool to hold pages of different sizes. - Innodb_buffer_pool_pages_data

The number of pages in the InnoDB buffer pool containing data. The number includes both dirty and clean pages. When using compressed tables, the reported Innodb_buffer_pool_pages_data value may be larger than Innodb_buffer_pool_pages_total (Bug #59550). - Innodb_buffer_pool_bytes_dirty

The total current number of bytes held in dirty pages in the InnoDB buffer pool. For more accurate memory usage calculations than with Innodb_buffer_pool_pages_dirty, when compressed tables cause the buffer pool to hold pages of different sizes. - Innodb_buffer_pool_pages_dirty

The current number of dirty pages in the InnoDB buffer pool. - Innodb_buffer_pool_pages_flushed

The number of requests to flush pages from the InnoDB buffer pool. - Innodb_buffer_pool_pages_free

The number of free pages in the InnoDB buffer pool. - Innodb_buffer_pool_pages_latched

The number of latched pages in the InnoDB buffer pool. These are pages currently being read or written, or that cannot be flushed or removed for some other reason. Calculation of this variable is expensive, so it is available only when the UNIV_DEBUG system is defined at server build time. - Innodb_buffer_pool_pages_misc

The number of pages in the InnoDB buffer pool that are busy because they have been allocated for administrative overhead, such as row locks or the adaptive hash index. This value can also be calculated as Innodb_buffer_pool_pages_total − Innodb_buffer_pool_pages_free − Innodb_buffer_pool_pages_data. When using compressed tables, Innodb_buffer_pool_pages_misc may report an out-of-bounds value (Bug #59550). - Innodb_buffer_pool_pages_total

The total size of the InnoDB buffer pool, in pages. When using compressed tables, the reported Innodb_buffer_pool_pages_data value may be larger than Innodb_buffer_pool_pages_total (Bug #59550) - Innodb_buffer_pool_read_ahead

The number of pages read into the InnoDB buffer pool by the read-ahead background thr

(本文超出站点单文档体积上限,已截断)