The server maintains many status variables that provide operational information. You can view these variables and their values using the SHOW STATUS statement. These values can help uncover key issues currently present in the database, such as
If Opened_tables is too large, your table_cache variable might be too small.
If key_reads is too large, your key_cache might be too small. The cache hit rate can be calculated as key_reads/key_read_requests.
If Handler_read_rnd is too large, you likely have many queries that require MySQL to scan entire tables or you have joins that do not use keys correctly.
…
The following is an excerpt from the MySQL 5 Chinese manual, detailing the meaning of each variable in show status.
mysql> SHOW STATUS;Reference Manual.
·
The number of connections that were aborted because the client died without closing the connection properly. See Section A.2.10, “Communication Errors and Aborted Connections”.
·
The number of failed attempts to connect to the MySQL server. See Section A.2.10, “Communication Errors and Aborted Connections”.
·
The number of transactions that used the temporary binary log cache but exceeded the value of binlog_cache_size and used a temporary file to store statements from the transaction.
·
The number of transactions that used the temporary binary log cache.
·
The number of bytes received from all clients.
·
The number of bytes sent to all clients.
·
The Com_xxx
The Com_stmt_xxx status variables are:
o
o
o
o
o
o
These variables stand for prepared statement commands. Their names correspond to the COM_xxx
All Com_stmt_xxx variables will increase, even if a statement argument is unknown or an error occurs during execution. In other words, their values correspond to the number of requests issued, not the number of requests successfully completed.
·
The number of connection attempts (successful or not) to the MySQL server.
·
The number of temporary tables on disk created automatically by the server while executing statements.
·
The number of temporary files mysqld has created.
·
The number of in-memory temporary tables created automatically by the server while executing statements. If Created_tmp_disk_tables is large, you may want to increase the tmp_table_size value to cause temporary tables to be memory-based instead of disk-based.
·
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 executed FLUSH statements.
·
The number of internal COMMIT statements.
·
The MySQL server can ask the NDB CLUSTER storage engine if it knows about a table with a given name. This is called discovery. Handler_discover indicates the number of times that tables have been discovered via this method.
·
The number of times that rows have been deleted from tables.
·
The number of times the first entry in an index was read. If this is high, it suggests that the server is doing a lot of full index scans; for example, SELECT col1 FROM foo, assuming col1 is indexed.
·
The number of requests to read a row based on a key. If this is high, it is a good indication that your queries and tables are properly indexed.
·
The number of requests to read the next row in key order. This value is increased if you are querying an index column with a range constraint or if you are performing 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 the entire table or you have joins that don’t 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 written queries do not take advantage of indexes.
·
The number of internal ROLLBACK statements.
·
The number of requests to update a row in a table.
·
The number of requests to insert a row into a table.
·
The number of pages containing data (dirty or clean).
·
The current number of dirty pages.
·
The number of buffer pool pages that have been requested to be flushed.
·
The number of free pages.
·
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.
·
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
·
The total size of the buffer pool, in pages.
·
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.
·
The number of sequential read-aheads initiated by InnoDB. This happens when InnoDB performs a sequential full table scan.
·
The number of logical read requests InnoDB has done.
·
The number of logical reads that InnoDB could not satisfy from the buffer pool and had to read a single page directly.
·
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.
·
The number of writes to the InnoDB buffer pool.
·
The number of fsync() operations.
·
The current number of pending fsync() operations.
·
The current number of pending reads.
·
The current number of pending writes.
·
The amount of data read so far, in bytes.
·
The total number of data reads.
·
The total number of data writes.
·
The amount of data written so far (in bytes).
·
The number of doublewrite operations that have been performed and the number of pages that have been written for this purpose. See Section 15.2.14.1, “Disk I/O”.
·
The number of times we had to wait because the log buffer was too small, and we had to wait 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 completed to the log file.
·
The number of pending log file fsync() operations.
·
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 easy conversion to bytes.
·
The number of pages created.
·
The number of pages read.
·
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.
·
The number of key blocks in the key cache that have been 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.3.3, “Server System Variables”.
·
The number of used blocks in the key cache. This value is a high-water mark, indicating 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 may be 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 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.
·
The number of streams that are open (used mainly for logging).
·
The number of tables that are currently open.
·
The number of tables that have been opened. If Opened_tables is large, your table_cache
·
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 number of queries added to the cache.
·
The number of queries that were deleted from the cache because of low memory.
·
The number of non-cached queries (not cacheable, or not cached due to the query_cache_type setting).
·
The number of queries registered in the cache.
·
The total number of blocks in the query cache.
·
The number of queries that have been sent to the server.
·
The fail-safe replication status (not yet in use).
·
The number of joins that 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.
·
The number of temporary tables that are currently open by the slave SQL thread.
·
This is ON if this server is a slave that is connected to a master.
·
The total number of times since startup that the replication slave SQL thread has retried transactions.
·
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. See Section 5.11.4, “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 completed by scanning the table.
·
Variables used for SSL connections.
·
The number of times a table lock was acquired immediately.
·
The number of times a table lock could not be acquired immediately. If this value is high and you have performance issues, you should first optimize your queries, then split tables or use replication.
·
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 large, you may want to increase the thread_cache_size value. The cache hit rate can be calculated as Threads_created/Connections.
·
The number of active (non-sleeping) threads.
·
The number of seconds the server has been running.