MySQL 數據庫的性能狀態監控點非常之多，其中很多量都是我們不能忽視的必須監控的
量，且90% 以上的內容可以在連接上MySQL Server 后執行“SHOW /*!50000 GLOBAL */
STATUS” 以及“SHOW /*!50000 GLOBAL */ VARIABLES” 的輸出值獲得。需要注意的是上
述命令所獲得狀態值實際上是累計值，所以如果要計算(單位/某個)時間段內的變化量還需
要稍加處理，可以在附錄中找到兩個命令輸出值的詳細說明。下面看看幾項需要重點關注的
性能狀態：
● QPS（每秒Query 量）：這里的QPS 實際上是指MySQL Server 每秒執行的Query
總量，在MySQL 5.1.30 及以下版本可以通過Questions 狀態值每秒內的變化量
來近似表示，而從MySQL 5.1.31 開始，則可以通過Queries 來表示。Queries 是
在MySQL 5.1.31 才新增的狀態變量。主要解決的問題就是Questions 狀態變量
并沒有記錄存儲過程中所執行的Query（當然，在無存儲過程的老版本MySQL 中
則不存在這個區別），而Queries 狀態變量則會記錄。二者獲取方式：
QPS = Questions(or Queries) / Seconds
獲取所需狀態變量值：
SHOW /*!50000 GLOBAL */ STATUS LIKE 'Questions'
SHOW /*!50000 GLOBAL */ STATUS LIKE 'Queries'
這里的Seconds 是指累計出上述兩個狀態變量值的時間長度，后面用到的地方也
代表同樣的意思。
● TPS（每秒事務量）： 在MySQL Server 中并沒有直接事務計數器，我們只能通過
回滾和提交計數器來計算出系統的事務量。所以，我們需要通過以下方式來得到客
戶端應用程序所請求的TPS 值：
TPS = (Com_commit + Com_rollback) / Seconds
如果我們還使用了分布式事務，那么還需要將Com_xa_commit 和
Com_xa_rollback 兩個狀態變量的值加上。
● Key Buffer 命中率：Key Buffer 命中率代表了MyISAM 類型表的索引的Cache
命中率。該命中率的大小將直接影響MyISAM 類型表的讀寫性能。Key Buffer 命
中率實際上包括讀命中率和寫命中率兩種，MySQL 中并沒有直接給出這兩個命中率
的值，但是可以通過如下方式計算出來：
key_buffer_read_hits = (1 - Key_reads / Key_read_requests) * 100%
key_buffer_write_hits= (1 - Key_writes / Key_write_requests) * 100%
獲取所需狀態變量值：
sky@localhost : (none) 07:44:10> SHOW /*!50000 GLOBAL */ STATUS
-> LIKE 'Key%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
... ...
| Key_read_requests | 10 |
| Key_reads | 4 |
| Key_write_requests | 0 |
| Key_writes | 0 |
+------------------------+-------+
通過這兩個計算公式，我們很容易就可以得出系統當前Key Buffer 的使用情況
● Innodb Buffer 命中率：這里Innodb Buffer 所指的是innodb_buffer_pool，也
就是用來緩存Innodb 類型表的數據和索引的內存空間。類似Key buffer，我們
同樣可以根據MySQL Server 提供的相應狀態值計算出其命中率：
innodb_buffer_read_hits=(1-
Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests) * 100%
獲取所需狀態變量值：
sky@localhost : (none) 08:25:14> SHOW /*!50000 GLOBAL*/ STATUS
-> LIKE 'Innodb_buffer_pool_read%';
+-----------------------------------+-------+
| Variable_name | Value |
+-----------------------------------+-------+
... ...
| Innodb_buffer_pool_read_requests | 5367 |
| Innodb_buffer_pool_reads | 507 |
+-----------------------------------+-------+
● Query Cache 命中率：如果我們使用了Query Cache，那么對Query Cache 命中
率進行監控也是有必要的，因為他可能告訴我們是否在正確的使用Query Cache。
Query Cache 命中率的計算方式如下：
Query_cache_hits= (Qcache_hits / (Qcache_hits + Qcache_inserts)) * 100%
獲取所需狀態變量值：
sky@localhost : (none) 08:32:01> SHOW /*!50000 GLOBAL*/ STATUS
-> LIKE 'Qcache%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
... ...
| Qcache_hits | 0 |
| Qcache_inserts | 0 |
... ...
+-------------------------+-------+
● Table Cache 狀態量：Table Cache 的當前狀態量可以幫助我們判斷系統參數
table_open_cache 的設置是否合理。如果狀態變量Open_tables 與
Opened_tables 之間的比率過低，則代表Table Cache 設置過小，個人認為該值
處于80% 左右比較合適。注意，這個值并不是準確的Table Cache 命中率。
獲取所需狀態變量值：
sky@localhost : (none) 08:52:00> SHOW /*!50000 GLOBAL*/ STATUS
-> LIKE 'Open%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
... ...
| Open_tables | 51 |
... ...
| Opened_tables | 61 |
+--------------------------+-------+
● Thread Cache 命中率：Thread Cache 命中率能夠直接反應出我們的系統參數
thread_cache_size 設置的是否合理。一個合理的thread_cache_size 參數能夠
節約大量創建新連接時所需要消耗的資源。Thread Cache 命中率計算方式如下：
Thread_cache_hits = (1 - Threads_created / Connections) * 100%
獲取所需狀態變量值：
sky@localhost : (none) 08:57:16> SHOW /*!50000 GLOBAL*/ STATUS
-> LIKE 'Thread%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
... ...
| Threads_created | 3 |
... ...
+-------------------+-------+
4 rows in set (0.01 sec)
sky@localhost : (none) 09:01:33> SHOW /*!50000 GLOBAL*/ STATUS
-> LIKE 'Connections';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Connections | 11 |
+---------------+-------+
正常來說，Thread Cache 命中率要在90% 以上才算比較合理。
● 鎖定狀態：鎖定狀態包括表鎖和行鎖兩種，我們可以通過系統狀態變量獲得鎖定總
次數，鎖定造成其他線程等待的次數，以及鎖定等待時間信息。
sky@localhost : (none) 09:01:44> SHOW /*!50000 GLOBAL*/ STATUS
-> LIKE '%lock%';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
... ...
| Innodb_row_lock_current_waits | 0 |
| Innodb_row_lock_time | 0 |
| Innodb_row_lock_time_avg | 0 |
| Innodb_row_lock_time_max | 0 |
| Innodb_row_lock_waits | 0 |
... ...
| Table_locks_immediate | 44 |
| Table_locks_waited | 0 |
+-------------------------------+-------+
通過上述系統變量，我們可以得出表鎖總次數，其中造成其他現線程等待的次數。
同時還可以得到非常詳細的行鎖信息，如行鎖總次數，行鎖總時間，每次行鎖等待
時間，行鎖造成最大等待時間以及當前等待行鎖的線程數。通過對這些量的監控，
我們可以清晰的了解到系統整體的鎖定是否嚴重。如當Table_locks_waited 與
Table_locks_immediate 的比值較大，則說明我們的表鎖造成的阻塞比較嚴重，可
能需要調整Query 語句，或者更改存儲引擎，亦或者需要調整業務邏輯。當然，
具體改善方式必須根據實際場景來判斷。而Innodb_row_lock_waits 較大，則說
明Innodb 的行鎖也比較嚴重，且影響了其他線程的正常處理。同樣需要查找出原
因并解決。造成Innodb 行鎖嚴重的原因可能是Query 語句所利用的索引不夠合
理（Innodb 行鎖是基于索引來鎖定的），造成間隙鎖過大。也可能是系統本身處理
能力有限，則需要從其他方面（如硬件設備）來考慮解決。
● 復制延時量：復制延時量將直接影響了Slave 數據庫處于不一致狀態的時間長短。
如果我們是通過Slave 來提供讀服務，就不得不重視這個延時量。我們可以通過
在Slave 節點上執行“SHOW SLAVE STATUS”命令，取Seconds_Behind_Master 項
的值來了解Slave 當前的延時量（單位：秒）。當然，該值的準確性依賴于復制是
否處于正常狀態。每個環境下的Slave 所允許的延時長短與具體環境有關，所以
復制延時多長時間是合理的，只能由讀者朋友根據各自實際的應用環境來判斷。
● Tmp table 狀況：Tmp Table 的狀況主要是用于監控MySQL 使用臨時表的量是否
過多，是否有臨時表過大而不得不從內存中換出到磁盤文件上。臨時表使用狀態信
息可以通過如下方式獲得：
sky@localhost : (none) 09:27:28> SHOW /*!50000 GLOBAL*/ STATUS
-> LIKE 'Created_tmp%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 1 |
... ...
| Created_tmp_tables | 46 |
+-------------------------+-------+
從上面的狀態信息可以了解到系統使用了46 次臨時表，其中有1 次臨時表比較大，
無法在內存中完成，而不得不使用到磁盤文件。如果Created_tmp_tables 非常大，
則可能是系統中排序操作過多，或者是表連接方式不是很優化。而如果是
Created_tmp_disk_tables 與Created_tmp_tables 的比率過高，如超過10%，則
我們需要考慮是否tmp_table_size 這個系統參數所設置的足夠大。當然，如果系
統內存有限，也就沒有太多好的解決辦法了。
● Binlog Cache 使用狀況：Binlog Cache 用于存放還未寫入磁盤的Binlog 信息。
相關狀態變量如下：
sky@localhost : (none) 09:40:38> SHOW /*!50000 GLOBAL*/ STATUS
-> LIKE 'Binlog_cache%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Binlog_cache_disk_use | 0 |
| Binlog_cache_use | 0 |
+-----------------------+-------+
如果Binlog_cache_disk_use 值不為0，則說明Binlog Cache 大小可能不夠，
建議增加binlog_cache_size 系統參數大小。
● Innodb_log_waits 量：Innodb_log_waits 狀態變量直接反應出Innodb Log
Buffer 空間不足造成等待的次數。
sky@localhost : (none) 09:43:53> SHOW /*!50000 GLOBAL*/ STATUS
-> LIKE 'Innodb_log_waits';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| Innodb_log_waits | 0 |
+------------------+-------+
該變量值發生的頻率將直接影響系統的寫入性能，所以當該值達到每秒1 次時就該
增加系統參數innodb_log_buffer_size 的值，畢竟這是一個系統共用的緩存，適
當增加并不會造成內存不足的問題。
上面這些監控量只是我個人認為比較重要的一些MySQL 性能監控量，各位讀者朋友還
可以根據各自的需要，通過MySQL 所提供的系統狀態變量增加其他監控內容。

【摘自《MySQL性能調優與架構設計》】

轉載于:https://blog.51cto.com/liaoen/1265738

總結

以上是生活随笔為你收集整理的衡量 mysql性能状态 参数 详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。