The SHOW
VARIABLES and SHOW
STATUS statements provide server
configuration and performance information:
mysql>SHOW VARIABLES;+---------------------------------+-------------------+ | Variable_name | Value | +---------------------------------+-------------------+ | back_log | 50 | | basedir | /usr/local/mysql/ | | bdb_cache_size | 8388600 | | bdb_log_buffer_size | 0 | | bdb_home | | ... mysql>SHOW /*!50002 GLOBAL */ STATUS;+--------------------------+----------+ | Variable_name | Value | +--------------------------+----------+ | Aborted_clients | 319 | | Aborted_connects | 22 | | Bytes_received | 32085033 | | Bytes_sent | 26379272 | | Connections | 65684 | ...
Both statements allow a LIKE
'
pattern
' clause that takes an SQL pattern. In that
case, only rows for variable names that match the pattern are
returned.
The /*!50002
GLOBAL
*/
comment is present in the SHOW
STATUS statement due to a change
made in MySQL 5.0.2; before MySQL 5.0.2, status variables were global
(server-wide values). In 5.0.2, status variables have global and
session (per-connection) values, and SHOW
STATUS has been extended to take GLOBAL or
SESSION modifiers,
with the default being, if neither is given, to display the session
values. The comment causes servers from MySQL 5.0.2 and up to display
the global values. Servers before 5.0.2 ignore the comment, but
display global values because only global values exist in those
versions. This idiom is used throughout this chapter.
System and status variable information can be useful for writing
administrative applications. For example, the MyISAM key cache hit
rate is a measure of how often key requests are satisfied from the
cache without reading keys from disk. The following formula calculates
the hit rate, where Key_reads and
Key_read_requests indicate the
number of disk reads and number of requests, respectively:
1 - (Key_reads / Key_read_requests)
Values close to 1 indicate a high hit rate, which means that the
key cache is very efficient. Values close to 0 indicate a low hit rate
(possibly a sign that you should increase the value of the key_buffer_size system variable to use a
larger cache). It’s easy to calculate the hit rate in a program, as
the following Ruby code illustrates:
# Execute SHOW STATUS to get relevant server status variables, use
# names and values to construct hash of values keyed by names.
stat_hash = {}
stmt = "SHOW /*!50002 GLOBAL */ STATUS LIKE 'Key_read%'"
dbh.select_all(stmt).each do |name, value|
stat_hash[name] = value
end
key_reads = stat_hash["Key_reads"].to_f
key_reqs = stat_hash["Key_read_requests"].to_f
hit_rate = key_reqs == 0 ? 0 : 1.0 - (key_reads / key_reqs)
puts " Key_reads: #{key_reads}"
puts "Key_read_requests: #{key_reqs}"
puts " Hit rate: #{hit_rate}"As another example, you might write a long-running program that probes the server periodically to monitor its activity. A simple application of this type might ask the server to report the number of connections it’s received and its uptime, to determine a running display of average connection activity. The statements to obtain this information are:
SHOW /*!50002 GLOBAL */ STATUS LIKE 'Connections'; SHOW /*!50002 GLOBAL */ STATUS LIKE 'Uptime';
If you want to avoid having to reconnect each time you issue the statements, you can ask the server for its client timeout period and probe it at intervals shorter than that value. You can get the timeout value (in seconds) with this statement:
SHOW VARIABLES LIKE 'wait_timeout';
The default value is 28800 (8 hours), but it might be configured to a different value on your system.
For system variables, an alternative way to access their values
is by referring to them as @@
var_name. For
example:
mysql>SELECT @@wait_timeout;
+----------------+
| @@wait_timeout |
+----------------+
| 28800 |
+----------------+This provides the convenience that you can select multiple values in a single row, and you can use the values directly within expressions.