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 13.7.5.36, “SHOW STATUS Syntax”).
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 |
+-----------------------------------+------------+
Several status variables provide statement counts. To determine the number of statements executed, use these relationships:
SUM(Com_xxx) + Qcache_hits = Questions + statements executed within stored programs = Queries
Many status variables are reset to 0 by the
FLUSH STATUS
statement.
The following table lists all available server status variables:
Table 5.4 Status Variable Summary
The status variables have the following meanings. For meanings of status variables specific to MySQL Cluster, see Section 18.3.3.8.3, “NDB Cluster Status Variables”.
The number of connections that were aborted because the client died without closing the connection properly. See Section B.5.2.11, “Communication Errors and Aborted Connections”.
The number of failed attempts to connect to the MySQL server. See Section B.5.2.11, “Communication Errors and Aborted Connections”.
The number of transactions that used the binary log cache but
that exceeded the value of
binlog_cache_size and used a
temporary file to store changes from the transaction.
In MySQL versions 5.5.3 through 5.5.8, this variable also
included the number of nontransactional statements that caused
the binary log transaction cache to be written to disk.
Beginning with MySQL 5.5.9, the number of such
nontransactional statements is tracked separately in the
Binlog_stmt_cache_disk_use
status variable.
The number of transactions that used the binary log cache.
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.
The number of nontransactional statements that used the binary log statement cache.
The number of bytes received from all clients.
The number of bytes sent to all clients.
The Com_
statement counter variables indicate the number of times each
xxxxxx 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.
If a query result is returned from query cache, the server
increments the Qcache_hits
status variable, not Com_select. See
Section 8.10.3.4, “Query Cache Status and Maintenance”.
The discussion at the beginning of this section indicates how to relate these statement-counting status variables to other such variables.
All of the
Com_stmt_
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.
xxx
The Com_stmt_
status variables are as follows:
xxx
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_ 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, xxxCom_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
after metadata changes to tables or views referred to by the
statement. A reprepare operation increments
Com_stmt_reprepare, and also
Com_stmt_prepare.
Whether the client connection uses compression in the client/server protocol.
The number of connection attempts (successful or not) to the MySQL server.
The number of internal on-disk temporary tables created by the server while executing statements.
If an internal temporary table is created initially as an
in-memory table but becomes too large, MySQL automatically
converts it to an on-disk table. The maximum size for
in-memory temporary tables is the minimum of the
tmp_table_size and
max_heap_table_size values.
If Created_tmp_disk_tables
is large, you may want to increase the
tmp_table_size or
max_heap_table_size value to
lessen the likelihood that internal temporary tables in memory
will be converted to on-disk tables.
You can compare the number of internal on-disk temporary
tables created to the total number of internal temporary
tables created by comparing the values of the
Created_tmp_disk_tables and
Created_tmp_tables
variables.
See also Section 8.4.4, “Internal Temporary Table Use in MySQL”.
How many temporary files mysqld has created.
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 the values of the
Created_tmp_disk_tables and
Created_tmp_tables
variables.
See also Section 8.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.
The number of rows written with INSERT
DELAYED for which some error occurred (probably
duplicate key).
The number of INSERT DELAYED
handler threads in use.
The number of INSERT DELAYED
rows written.
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.
The number of internal COMMIT
statements.
The number of times that rows have been deleted from tables.
A counter for the prepare phase of two-phase commit operations.
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.
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.
The number of requests to read the last key in an index. With
ORDER BY, the server will issue a first-key
request followed by several next-key requests, whereas with
ORDER BY DESC, the server will issue a
last-key request followed by several previous-key requests.
This variable was added in MySQL 5.5.7.
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.
The number of requests to read the previous row in key order.
This read method is mainly used to optimize ORDER BY
... DESC.
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.
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.
The number of requests for a storage engine to perform a rollback operation.
The number of requests for a storage engine to place a savepoint.
The number of requests for a storage engine to roll back to a savepoint.
The number of requests to update a row in a table.
The number of requests to insert a row in a table.
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.
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 number of pages currently dirty.
Innodb_buffer_pool_pages_flushed
The number of buffer pool page-flush requests.
The number of free pages.
Innodb_buffer_pool_pages_latched
The number of latched pages in 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.
The number of pages 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)
The number of pages read into the InnoDB
buffer pool by the read-ahead background thread.
Innodb_buffer_pool_read_ahead_evicted
The number of pages read into the InnoDB
buffer pool by the read-ahead background thread that were
subsequently evicted without having been accessed by queries.
Innodb_buffer_pool_read_ahead_rnd
The number of “random” read-aheads initiated by
InnoDB. This happens when a query scans a
large portion of a table but in random order.
Innodb_buffer_pool_read_requests
The number of logical read requests.
The number of logical reads that InnoDB
could not satisfy from the buffer pool, and had to read
directly from the disk.
Normally, writes to the InnoDB buffer pool
happen in the background. However, if it is necessary to read
or create a page and no clean pages are available, it is also
necessary to wait for pages to be flushed first. This counter
counts instances of these waits. If the buffer pool size has
been set properly, this value should be small.
Innodb_buffer_pool_write_requests
The number writes done to the InnoDB buffer
pool.
The number of fsync() operations so far.
The current number of pending fsync()
operations.
The current number of pending reads.
The current number of pending writes.
The amount of data read since the server was started (in bytes).
The total number of data reads (OS file reads).
The total number of data writes.
The amount of data written so far, in bytes.
The number of pages that have been written for doublewrite operations. See Section 14.15.1, “InnoDB Disk I/O”.
The number of doublewrite operations that have been performed. See Section 14.15.1, “InnoDB Disk I/O”.
Indicates whether the server was built with atomic instructions.
The number of times that the log buffer was too small and a wait was required for it to be flushed before continuing.
The number of log write requests.
The number of physical writes to the log file.
The number of fsync() writes done to the
log file.
The number of pending log file fsync()
operations.
The number of pending log file writes.
The number of bytes written to the log file.
The compiled-in InnoDB page size (default
16KB). Many values are counted in pages; the page size enables
them to be easily converted to bytes.
The number of pages created.
The number of pages read from the InnoDB
buffer pool by operations on InnoDB tables.
The number of pages written.
The number of row locks currently being waited for.
The total time spent in acquiring row locks, in milliseconds.
The average time to acquire a row lock, in milliseconds.
The maximum time to acquire a row lock, in milliseconds.
The number of times a row lock had to be waited for.
The number of rows deleted from InnoDB
tables.
The number of rows inserted into InnoDB
tables.
The number of rows read from InnoDB tables.
The number of rows updated in InnoDB
tables.
Innodb_truncated_status_writes
The number of times output from the SHOW ENGINE
INNODB STATUS is truncated. Monitoring applications
that parse the output from this command can test this value
before and after issuing the SHOW ENGINE
command, to confirm if the output is complete or not.
The number of key blocks in the key cache that have changed but have not yet been flushed to disk.
The number of unused blocks in the key cache. You can use this
value to determine how much of the key cache is in use; see
the discussion of
key_buffer_size in
Section 5.1.5, “Server System Variables”.
The number of used blocks in the key cache. This value is a high-water mark that indicates the maximum number of blocks that have ever been in use at one time.
The number of requests to read a key block from the cache.
The number of physical reads of a key block from disk. If
Key_reads is large, then
your key_buffer_size value is
probably too small. The cache miss rate can be calculated as
Key_reads/Key_read_requests.
The number of requests to write a key block to the cache.
The number of physical writes of a key block to disk.
The total cost of the last compiled query as computed by the
query optimizer. This is useful for comparing the cost of
different query plans for the same query. The default value of
0 means that no query has been compiled yet. The default value
is 0. Last_query_cost has
session scope.
The Last_query_cost value
can be computed accurately only for simple “flat”
queries, not complex queries such as those with subqueries or
UNION. For the latter, the
value is set to 0.
The maximum number of connections that have been in use simultaneously since the server started.
The number of rows waiting to be written in
INSERT DELAYED queues.
The number of files that are open. This count includes regular files opened by the server. It does not include other types of files such as sockets or pipes. Also, the count does not include files that storage engines open using their own internal functions rather than asking the server level to do so.
The number of streams that are open (used mainly for logging).
The number of cached .frm files.
The number of tables that are open.
The number of files that have been opened with
my_open() (a mysys
library function). Parts of the server that open files without
using this function do not increment the count.
The number of .frm files that have been
cached.
The number of tables that have been opened. If
Opened_tables is big, your
table_open_cache value is
probably too small.
Performance_schema_
xxx
Performance Schema status variables are listed in Section 22.11, “Performance Schema Status Variables”. These variables provide information about instrumentation that could not be loaded or created due to memory constraints.
The current number of prepared statements. (The maximum number
of statements is given by the
max_prepared_stmt_count
system variable.)
The number of free memory blocks in the query cache.
The amount of free memory for the query cache.
The number of query cache hits.
The discussion at the beginning of this section indicates how to relate this statement-counting status variable to other such variables.
The number of queries added to the query cache.
The number of queries that were deleted from the query cache because of low memory.
The number of noncached queries (not cacheable, or not cached
due to the query_cache_type
setting).
The number of queries registered in the query cache.
The total number of blocks in the query cache.
The number of statements executed by the server. This variable
includes statements executed within stored programs, unlike
the Questions variable. It
does not count COM_PING or
COM_STATISTICS commands.
The discussion at the beginning of this section indicates how to relate this statement-counting status variable to other such variables.
The number of statements executed by the server. This includes
only statements sent to the server by clients and not
statements executed within stored programs, unlike the
Queries variable. This
variable does not count COM_PING,
COM_STATISTICS,
COM_STMT_PREPARE,
COM_STMT_CLOSE, or
COM_STMT_RESET commands.
The discussion at the beginning of this section indicates how to relate this statement-counting status variable to other such variables.
The number of semisynchronous slaves.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_net_avg_wait_time
The average time in microseconds the master waited for a slave reply.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_net_wait_time
The total time in microseconds the master waited for slave replies.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_net_waits
The total number of times the master waited for slave replies.
This variable is available only if the master-side semisynchronous replication plugin is installed.
The number of times the master turned off semisynchronous replication.
This variable is available only if the master-side semisynchronous replication plugin is installed.
The number of commits that were not acknowledged successfully by a slave.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Whether semisynchronous replication currently is operational
on the master. The value is ON if the
plugin has been enabled and a commit acknowledgment has
occurred. It is OFF if the plugin is not
enabled or the master has fallen back to asynchronous
replication due to commit acknowledgment timeout.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_timefunc_failures
The number of times the master failed when calling time
functions such as gettimeofday().
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_tx_avg_wait_time
The average time in microseconds the master waited for each transaction.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_tx_wait_time
The total time in microseconds the master waited for transactions.
This variable is available only if the master-side semisynchronous replication plugin is installed.
The total number of times the master waited for transactions.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_wait_pos_backtraverse
The total number of times the master waited for an event with binary coordinates lower than events waited for previously. This can occur when the order in which transactions start waiting for a reply is different from the order in which their binary log events are written.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_wait_sessions
The number of sessions currently waiting for slave replies.
This variable is available only if the master-side semisynchronous replication plugin is installed.
The number of commits that were acknowledged successfully by a slave.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Whether semisynchronous replication currently is operational
on the slave. This is ON if the plugin has
been enabled and the slave I/O thread is running,
OFF otherwise.
This variable is available only if the slave-side semisynchronous replication plugin is installed.
The status of fail-safe replication (not implemented). This variable is unused and is removed in MySQL 5.6.
The number of joins that perform table scans because they do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.
The number of joins that used a range search on a reference table.
The number of joins that used ranges on the first table. This is normally not a critical issue even if the value is quite large.
The number of joins without keys that check for key usage after each row. If this is not 0, you should carefully check the indexes of your tables.
The number of joins that did a full scan of the first table.
Shows the replication heartbeat interval (in seconds) on a replication slave.
The number of temporary tables that the slave SQL thread currently has open. If the value is greater than zero, it is not safe to shut down the slave; see Section 17.4.1.24, “Replication and Temporary Tables”.
This counter increments with each replication heartbeat
received by a replication slave since the last time that the
slave was restarted or reset, or a CHANGE
MASTER TO statement was issued.
The total number of times since startup that the replication slave SQL thread has retried transactions.
This is ON if this server is a replication
slave that is connected to a replication master, and both the
I/O and SQL threads are running; otherwise, it is
OFF.
The number of threads that have taken more than
slow_launch_time seconds to
create.
The number of queries that have taken more than
long_query_time seconds. This
counter increments regardless of whether the slow query log is
enabled. For information about that log, see
Section 5.4.5, “The Slow Query Log”.
The number of merge passes that the sort algorithm has had to
do. If this value is large, you should consider increasing the
value of the sort_buffer_size
system variable.
The number of sorts that were done using ranges.
The number of sorted rows.
The number of sorts that were done by scanning the table.
The number of negotiates needed to establish the connection.
The number of accepted SSL connections.
The number of callback cache hits.
The current encryption cipher (empty for unencrypted connections).
The list of possible SSL ciphers (empty for non-SSL connections).
The number of SSL connection attempts to an SSL-enabled master.
The number of negotiates needed to establish the connection to an SSL-enabled master.
The SSL context verification depth (how many certificates in the chain are tested).
The SSL context verification mode.
The default SSL timeout.
The number of successful SSL connections to the server.
The number of successful slave connections to an SSL-enabled master.
The number of SSL session cache hits.
The number of SSL session cache misses.
The SSL session cache mode.
The number of SSL session cache overflows.
The SSL session cache size.
The number of SSL session cache timeouts.
How many SSL connections were reused from the cache.
Ssl_used_session_cache_entries
How many SSL session cache entries were used.
The verification depth for replication SSL connections.
The verification mode for replication SSL connections.
The SSL protocol version of the connection; for example, TLSv1. If the connection is not encrypted, the value is empty.
The number of times that a request for a table lock could be granted immediately.
The number of times that a request for a table lock could not be granted immediately and a wait was needed. If this is high and you have performance problems, you should first optimize your queries, and then either split your table or tables or use replication.
For the memory-mapped implementation of the log that is used
by mysqld when it acts as the transaction
coordinator for recovery of internal XA transactions, this
variable indicates the largest number of pages used for the
log since the server started. If the product of
Tc_log_max_pages_used and
Tc_log_page_size is always
significantly less than the log size, the size is larger than
necessary and can be reduced. (The size is set by the
--log-tc-size option. This
variable is unused: It is unneeded for binary log-based
recovery, and the memory-mapped recovery log method is not
used unless the number of storage engines that are capable of
two-phase commit and that support XA transactions is greater
than one. (InnoDB is the only applicable
engine.)
The page size used for the memory-mapped implementation of the
XA recovery log. The default value is determined using
getpagesize(). This variable is unused for
the same reasons as described for
Tc_log_max_pages_used.
For the memory-mapped implementation of the recovery log, this
variable increments each time the server was not able to
commit a transaction and had to wait for a free page in the
log. If this value is large, you might want to increase the
log size (with the
--log-tc-size option). For
binary log-based recovery, this variable increments each time
the binary log cannot be closed because there are two-phase
commits in progress. (The close operation waits until all such
transactions are finished.)
The number of threads in the thread cache.
The number of currently open connections.
The number of threads created to handle connections. If
Threads_created is big, you
may want to increase the
thread_cache_size value. The
cache miss rate can be calculated as
Threads_created/Connections.
The number of threads that are not sleeping.
The number of seconds that the server has been up.
The number of seconds since the most recent FLUSH
STATUS statement.