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

【摘自《MySQL性能調(diào)優(yōu)與架構(gòu)設(shè)計(jì)》】

轉(zhuǎn)載于:https://blog.51cto.com/liaoen/1265738

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。