mysql 監控指標

mysql(RDS)常用性能指標監控

一、Mysql

1.1.1 監控指標說明

主要針對 SQL 耗時、吞吐量（QPS TPS）命中率 鎖等待等指標進行監控。

• 本來運維工具產品有以下參數：(global status裏面的狀態量)
  TPS/QPS
  連接數
  每秒SQL執行次數
  全表掃描數
  InnoDB緩衝池命中率
  InnoDB緩衝池使用率/髒塊率
  InnoDB邏輯讀
  排序記錄數
  InnoDB鎖等待次數
  InnoDB 髒頁數量
  InnoDB 讀寫量
  InnoDB buffer pool 讀寫次數
  InnoDB 日誌文件寫次數
  打開文件/表數量
  慢 SQL
  MyISAM 讀寫次數
  MyISAM key Buffer 讀/寫/利用率(%)
  MySQL 執行語句時在硬盤上自動創建的臨時表的數量

指標	解釋
TPS	是Transactions Per Second的縮寫，也就是事務數/秒。它是軟件測試結果的測量單位。一個事務是指一個客戶機向服務器發送請求然後服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應後結束計時，以此來計算使用的時間和完成的事務個數。
QPS	是Queries Per Second的縮寫，意思是每秒查詢率，是一臺服務器每秒能夠相應的查詢次數，是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。
連接數	當前總連接數 The number of connection attempts (successful or not) to the MySQL server. Connections
每秒 SQL 執行次數	insert delete update select語句 ROWDML：InnoDB每秒鐘操作數據行數的統計，根據操作的不同，分爲平均每秒向日志文件的物理寫次數、平均每秒從InnoDB表“刪除/更新/讀取/插入”的行數。
全表掃描數	平均每秒全表掃描次數 show global status like “handler_read%”
InnoDB 緩衝池命中率	InnoDB buffer pool hit 不低於95%
InnoDB 緩衝池使用率/髒塊率	InnoDB 緩衝池的讀命中率、利用率以及緩衝池髒塊的百分率(InnoDB緩衝池)
InnoDB 物理讀	innodb_buffer_pool_reads: 平均每秒從物理磁盤讀取頁的次數
InnoDB 邏輯讀	innodb_buffer_pool_read_requests: 平均每秒從innodb緩衝池的讀次數
排序記錄數	Sort_rows
InnoDB 鎖等待次數	Innodb_row_lock_current_waits
InnoDB 髒頁數量	innodb_buffer_pool_pages_dirty
InnoDB 讀寫量	InnoDB 每秒鐘的讀取和寫入次數。/innodb_data_read innodb_data_written
InnoDB buffer pool 讀寫次數	innodb_buffer_pool_read_requests/ innodb_buffer_pool_write_requests
InnoDB日誌文件寫次數	InnoDB日誌：InnoDB的日誌寫入情況/ Innodb_log_writes
打開文件/表數量	Innodb_num_open_files/Com_show_open_tables
慢SQL	Slow_queries
MyISAM讀寫次數	MyISAM平均每秒的讀寫次數。 key_read_requests/ key_write_requests
MyISAM key Buffer 讀/寫/利用率(%)	MyISAM平均每秒的Key Buffer使用狀況。Key_usage_ratio =Key_blocks_used/(Key_blocks_used+Key_blocks_unused)*100 —- Key_read_hit_ratio=(1-Key_reads/Key_read_requests)*100 — Key_write_hit_ratio =(1-Key_writes/Key_write_requests)*100
MySQL執行語句時在硬盤上自動創建的臨時表的數量	執行語句時在硬盤上自動創建的臨時表的數量（臨時表）Created_tmp_disk_tables
IOPS	RDS實例的IOPS（每秒 IO 請求次數）

系統吞吐量要素：
一個系統的吞吐量（承壓能力）與 request 對 CPU 的消耗、外部接口、IO等等緊密關聯。單個request 對CPU消耗越高，外部系統接口、IO速度越慢，系統吞吐能力越低，反之越高。
 
系統吞吐量幾個重要參數：QPS（TPS）、併發數、響應時間

        QPS（TPS）：（Query Per Second）每秒鐘request/事務 數量

        併發數： 系統同時處理的request/事務數

        響應時間：  一般取平均響應時間

（很多人經常會把併發數和TPS理解混淆）

理解了上面三個要素的意義之後，就能推算出它們之間的關係：
QPS（TPS）= 併發數/平均響應時間    或者   併發數 = QPS*平均響應時間

TPS/QPS區別及理解：

1、TPS即每秒處理事務數，包括：”用戶請求服務器”、”服務器自己的內部處理”、”服務器返回給用戶”，這三個過程，每秒能夠完成N個這三個過程，TPS也就是3；
2、QPS基本類似於TPS，但是不同的是，對於一個頁面的一次訪問，形成一個TPS；但一次頁面請求，可能產生多次對服務器的請求，服務器對這些請求，就可計入QPS之中。
3、一般的，評價系統性能均以每秒鐘完成的技術交易的數量來衡量。系統整體處理能力取決於處理能力最低模塊的TPS值。
4、QPS 對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力。

MySQL RDS磁盤佔用包括日誌文件（binlog文件、錯誤日誌等），數據文件（數據、索引文件），和一些其他文件（ibdata，logfile_0,臨時文件等）
造成 MySQL 實例空間使用率過高，主要有如下四種原因：
Binlog 文件佔用高。
數據文件佔用高。
臨時文件佔用高。
系統文件佔用高。

對應解決方法：
1、定期刪除binlog，假如當前dml造成大量的binlog，可以通過RDS控制檯即使清理binlog
2、通過 truncate 或者 drop 及時清除不需要的表
3、終止對應的回話
4、ibdata 中 undo 佔用高可以進行undo分離，或者進行數據轉移；增加redo log file的大小和組數

磁盤空間、磁盤空間詳情：

這段時間的數據是一條直線，空間狀態都很穩定，沒有性能問題。

MySQL RDS磁盤佔用包括日誌文件（binlog文件、錯誤日誌等），數據文件（數據、索引文件），和一些其他文件（ibdata，logfile_0,臨時文件等）

造成 MySQL 實例空間使用率過高，主要有如下四種原因：

Binlog 文件佔用高。

數據文件佔用高。

臨時文件佔用高。

系統文件佔用高。

對應解決方法：

1、定期刪除binlog，假如當前dml造成大量的binlog，可以通過RDS控制檯即使清理binlog

2、通過truncate或者drop及時清除不需要的表

3、終止對應的回話

4、ibdata中undo佔用高可以進行undo分離，或者進行數據轉移；增加redo log file的大小和組數

MySQL內存使用率：

基本上是一條直線，沒有變化。因爲MySQL有innodb_buffer_pool，大約爲物理內存的50%-80%，內存使用率高一些，相對的性能也會提高

cpu/mem的使用率：

現在cpu的使用率在30%左右，不算高。內存的使用率基本平穩在30%左右，正常

CPU的使用率高的原因：

• 系統執行應用提交查詢（包括數據修改操作）時需要大量的邏 輯讀，（邏輯 IO，執行查詢所需訪問的表的數據行數），需要消耗大量的 CPU 資源以維護從存儲系統讀取到內存中的數據一致性。造成邏輯讀高的原因，很可能是異常SQL，掃描的數據行數過多導致。

物理內存：

直線保持基本無變化，物理內存就是實際的內存條的內存大小

連接數：show processlist

連接數是指用戶能夠創建多少個連接，也就是MySQL show processlist命令輸出結果中運行着的線程個數。
當前總連接數： show processlist 結果中的總線程個數
當前活躍連接數：show processlist 結果中的活躍線程數(Command列狀態爲sleep的不計入在內)

當前連接數在1500左右，後來增高至6000左右。但是活躍連接數一直在個位數，說明現在的空閒連接數過多。總連接數超過參考值2000。出現嚴重問題。

數據庫的連接一般是使用長連接，可能是應用側的連接池初始連接數設置過高，應用啓動後建立多個到RDS的空閒連接

解決方法：

• 1、長連接建議啓用連接池的複用連接功能。
• 2、對於交互式連接和非交互式連接，建議修改相應的wait_timeout和interactive_timeout參數。（空閒時間超過指定的時間後，RDS的連接會主動關閉）。通過DT，RDS控制檯，性能優化，參數設置中修改。
• 3、kill當前的空閒會話。

網絡流量：

Bytes_received/s：平均每秒的輸入流量，單位byte/s
Bytes_sent/s：平均每秒的輸出流量，單位byte/s

IOPS：

每秒讀寫的次數。現在是比較小的。在0-0.2之間。

如果IOPS比較高的話，有可能是以下原因：

1、實例內存滿足不了緩存數據或排序等需要，導致產生大量的物理 IO。

2、查詢執行效率低，掃描過多數據行。

解決方法：

1、查詢是否有慢SQL，優化慢SQL，可以參考杜康的實例卡慢診斷的優化建議，或者登錄DMS，通過診斷報告、優化來進行SQL優化
2、終止查詢語句
3、通過show processlist，或者DMS控制檯、杜康等來kill查詢回話id

QPS/TPS：

TPS= Com_insert/s + Com_update/s + Com_delete/s
QPS=Com_select/s + Com_insert/s + Com_update/s + Com_delete/s
官方文檔入口com
QPS比較高，在90000左右，最高到達110000 。每秒的事務數在10000以上。正常，業務量比較高

原因分析：

• QPS比較高，每秒SQL的語句執行次數高，業務量上來，處於業務的高峯期，用戶連接數增加，訪問量增加。
• 如果QPS比較高，邏輯讀不高，慢SQL也不是系統的瓶頸，QPS和cpu使用率的變化曲線吻合，這時候優化的餘地就不高了，可以從實例規格、應用架構方面進行考慮。
• 如果QPS不高，查詢執行效率低、執行時需要掃描大量表中數據、優化餘地大，並且出現慢查詢問題，QPS和CPU的變化曲線不吻合
• 如果QPS比較高，並且邏輯讀也比較高，CPU的使用率增加，這時候可以優化優化相應的慢SQL，添加主實例的只讀實例來緩解壓力。

COMDML：

Com_select/s：平均每秒select語句執行次數

Com_insert/s：平均每秒insert語句執行次數

Com_update/s：平均每秒update語句執行次數

Com_delete/s：平均每秒delete語句執行次數

ROWDML：

innodb_rows_deleted: 平均每秒從innodb表刪除的行數

innodb_rows_inserted: 平均每秒從innodb表插入的行數

innodb_rows_read: 平均每秒從innodb表讀取的行數

innodb_rows_updated: 平均每秒從innodb表更新的行數

Innodb緩衝池：

緩衝池(innodb buffer pool)簡單來說就是一塊內存區域。緩衝池中緩存的數據頁類型有：索引頁、數據頁、undo頁、插入緩衝、自適應哈希索引、InnoDB存儲的鎖信息、數據字典信息等。不能簡單認爲，緩衝池只是緩存索引頁和數據頁，它們只是佔緩衝池很大的一部分而已。

在數據庫中進行讀取頁的操作，首先將從磁盤讀到的頁存放在緩衝池中，下一次再讀相同的頁時，首先判斷該頁是否在緩衝池中。若在，稱該頁在緩衝池中被命中，直接讀取該頁。否則，讀取磁盤中的頁。

innodb_buffer_pool_reads: 平均每秒從物理磁盤讀取頁的次數

innodb_buffer_pool_read_requests: 平均每秒從innodb緩衝池的讀次數

innodb_buffer_pool_write_requests: 平均每秒向innodb緩衝池的寫次數

innodb_buffer_pool_pages_dirty: 平均每秒innodb緩存池中髒頁的數目

innodb_buffer_pool_pages_flushed: 平均每秒innodb緩存池中刷新頁請求的數目

緩衝池的讀命中率

innodb_buffer_read_hit_ratio = ( 1 – innodb_buffer_pool_reads/innodb_buffer_pool_read_requests) * 100

緩衝池的利用率

innodb_buffer_usage = ( 1 – innodb_buffer_pool_pages_free / innodb_buffer_pool_pages_total) * 100

緩衝池的髒塊的百分率

innodb_buffer_pool_pages_dirty / innodb_buffer_pool_pages_total

Innodb讀寫量：

平均每秒讀取的數據量：innodb_data_read

平均每秒寫入的數據量：innodb_data_written

Innodb讀寫次數：

平均每秒Innodb從文件中讀取的次數：innodb_data_reads

平均每秒Innodb從文件中寫入的次數：innodb_data_writes

Innodb日誌：

平均每秒向日志文件的物理寫次數：innodb_log_writes

平均每秒日誌寫請求次數：innodb_log_write_requests

平均每秒向日志文件完成fsync()寫數量：innodb_os_log_fsyncs

臨時表：

Created_tmp_disk_tables：MySQL執行語句時在磁盤上自動創建的臨時表的數量

在某些情況下，MySQL服務器會自動創建內部臨時表。用explain查看select語句的執行計劃，如果extra列顯示“using temporary”,即使用了內部臨時表。一般情況下，MySQL會先創建內存臨時表，內存臨時表超過配置指定的值後，MySQL會將內存臨時表導出到磁盤臨時表。

使用臨時表一般都意味着性能比較低，特別是使用磁盤臨時表，性能更慢，因此我們在實際應用中應該儘量避免臨時表的使用。常見的方法有：

1)創建索引：在ORDER BY或者GROUP BY的列上創建索引；

2)分拆很長的列：一般情況下，TEXT、BLOB，大於512字節的字符串，基本上都是爲了顯示信息，而不會用於查詢條件， 因此表設計的時候，應該將這些列獨立到另外一張表。

如果表的設計已經確定，修改比較困難，那麼也可以通過優化SQL語句來減少臨時表的大小，以提升SQL執行效率。

MyISAM Key Buffer：

爲了最小化磁盤I/O，MyISAM將最頻繁訪問的索引塊(Index block)都放在內存中，這樣的內存緩衝區我們稱之爲Key Cache，它的大小可以通過參數key_buffer_size來控制。在MyISAM的索引文件中，連續的單元組成一個Block，Index block的大小等於該BTree索引節點的大小。Key Cache就是以Block爲單位的。

當MySQL請求(讀或寫)MyISAM索引文件中某個Index Block時，首先會看Key Cache隊列中是否已經緩存了對應block。

如果有，就直接在Key Cache隊列中進行讀寫了，不再需要請求磁盤。如果是寫請求，那麼Key Cache中的對應Block就會被標記爲Dirty(和磁盤不一致)。在MyISAM在Key Cache成功請求(讀寫)某個Block後，會將該Block放到Key Cache隊列的頭部。

如果Key Cache中沒有待請求(讀或寫)的Block，MyISAM會向磁盤請求對應的Block，並將其放到Key Cache的隊列頭部。隊列如果滿了，會將隊列尾部的Block刪除，該Block如果是Dirty的，會將其Flush到磁盤上。我們看到MyISAM維護了一個LRU(Least Recently Used)的Key Cache隊列。隊列中的Dirty Block會在Block被踢出隊列時Flush到磁盤上。

MyISAM平均每秒key buffer利用率

Key_usage_ratio =Key_blocks_used/(Key_blocks_used+Key_blocks_unused)*100

MyISAM平均每秒key buffer讀命中率

Key_read_hit_ratio=(1-Key_reads/Key_read_requests)*100

MyISAM平均每秒key buffer寫命中率

Key_write_hit_ratio =(1-Key_writes/Key_write_requests)*100

MyISAM讀寫次數：

key_read_requests: MyISAM平均每秒鐘從緩衝池中的讀取次數

Key_write_requests: MyISAM平均每秒鐘從緩衝池中的寫入次數

key_reads : MyISAM平均每秒鐘從硬盤上讀取的次數

key_writes : MyISAM平均每秒鐘從硬盤上寫入的次數

線程狀態：

線程數跟連接數是對應的。此時也是連接的總線程數遠大於活躍的線程數。

備庫延遲：

目前主備延遲(slave-lag)爲0.

主備延遲產生的原因：

• 1 主庫產生非常大的binlog

a) 主庫上執行大量的dml語句

b) 主庫上執行大事務

c) 主庫上沒有主鍵的全表掃描

• 2 主庫上執行ddl語句，時間過長
• 3 備庫上對myisam表長時間查詢，阻塞主庫的binlog同步語句
• 4 備庫實例的規格配置低，磁盤IO比較低

查看方法:

• 1 首先查看備庫的IOPS是否存在瓶頸
• 2 備庫show processlist查看是否存在大事務
• 3 主庫的寫入壓力是否過高，dml語句是否過多
• 4 只讀節點執行 show slave status \G，判斷是否有 Waiting for table metadata lock；同時在主庫排查下是否有DDL 操作
• 5 只讀節點執行 show slave status \G，判斷是否有 Waiting for table level lock; 同時通過 show full processlist; 同時在主庫檢查下是否有長時間對 MyISAM 引擎表的查詢

慢SQL：

慢SQL數量的變化曲線跟CPU的使用率的變化曲線吻合，在CPU使用率高的時候，慢SQL也跟着增加。可以通過杜康對產生的慢SQL進行優化。

全表掃描次數：

handeler_read%
隨着業務量的增加，全表掃描的次數也隨之增加。Sql要儘量避免全表掃描

主實例問題與建議：

QPS升高，業務量高的情況下，產生一些慢查詢SQL，並且空閒連接數太多

• 連接數：連接數嚴重超過參考值，並且有過多的空閒線程。首先檢查應用是否使用連接池，如果使用連接池，檢查連接池的配置是否合理

  • 優化慢SQL

root@itpux 12:14:  [(none)]> show global status like "%innodb%read%"\G
*************************** 1. row ***************************
Variable_name: Innodb_buffer_pool_read_ahead_rnd
        Value: 0
*************************** 2. row ***************************
Variable_name: Innodb_buffer_pool_read_ahead
        Value: 0
*************************** 3. row ***************************
Variable_name: Innodb_buffer_pool_read_ahead_evicted
        Value: 0
*************************** 4. row ***************************
Variable_name: Innodb_buffer_pool_read_requests
        Value: 1356
*************************** 5. row ***************************
Variable_name: Innodb_buffer_pool_reads
        Value: 240
*************************** 6. row ***************************
Variable_name: Innodb_data_pending_reads
        Value: 0
*************************** 7. row ***************************
Variable_name: Innodb_data_read
        Value: 4002304
*************************** 8. row ***************************
Variable_name: Innodb_data_reads
        Value: 271
*************************** 9. row ***************************
Variable_name: Innodb_pages_read
        Value: 239
*************************** 10. row ***************************
Variable_name: Innodb_rows_read
        Value: 8
10 rows in set (0.00 sec)

參數	說明
Innodb_buffer_pool_read_ahead	預讀次數
Innodb_buffer_pool_read_ahead_evicted	預讀的頁，但沒有被讀取就從緩衝池中被替換的頁的數量，一般用來判斷預讀的效率
Innodb_buffer_pool_read_requests	從緩存池中讀取頁的次數
Innodb_buffer_pool_reads	從物理磁盤讀取頁的次數
Innodb_data_read	總共讀入的字節數
Innodb_data_reads	發起讀取請求的次數，每次讀取可能需要讀取多個頁

二、緩衝池命中率:

= Innodb_buffer_pool_reads/(Innodb_buffer_pool_reads+Innodb_buffer_pool_read_ahead+Innodb_buffer_pool_read_requests)
參考鏈接

三、mysql 之常規應監控的指標

一，Mysql 之線程

Uptime_since_flush_status --最近一次使用FLUSH STATUS 的時間（以秒爲單位）

Uptime --服務器已經運行的時間（以秒爲單位）

Threads_running --激活的（非睡眠狀態）線程數。

Threads_created --創建用來處理連接的線程數。如果Threads_created較大，你可能要增加thread_cache_size值。 緩存訪問率的計算方法Threads_created/Connections。

Threads_connected --當前打開的連接的數量。

Threads_cached --線程緩存內的線程的數量。

二，Mysql之表鎖

Table_locks_waited --不能立即獲得的表的鎖的次數。如果該值較高，並且有性能問題，你應首先優化查詢，然後拆分表或使用複製。

Table_locks_immediate --立即獲得的表的鎖的次數。

三，Mysql 之sort

Sort_scan --通過掃描表完成的排序的數量。

Sort_rows --已經排序的行數。

Sort_range --在範圍內執行的排序的數量

Sort_merge_passes --排序算法已經執行的合併的數量。如果這個變量值較大，應考慮增加sort_buffer_size系統 變量的值。

四，Mysql 之 慢查詢

Slow_queries --查詢時間超過long_query_time秒的查詢的個數。

Slow_launch_threads --創建時間超過slow_launch_time秒的線程數。

五，mysql 之 innodb_buffer_pool

Innodb_buffer_pool_pages_data --包含數據的頁數(髒或乾淨)

Innodb_buffer_pool_pages_total --緩衝池總大小（頁數）

Innodb_buffer_pool_read_ahead_rnd --InnoDB初始化的“隨機”read-aheads數。 當查詢以隨機順序掃描表的一大部分時發生。

Innodb_buffer_pool_read_ahead_seq --InnoDB初始化的順序read-aheads數。當InnoDB執 行順序全表掃描時發生。

Innodb_buffer_pool_read_requests --InnoDB已經完成的邏輯讀請求數。

Innodb_buffer_pool_reads --不能滿足InnoDB必須單頁讀取的緩衝池中的邏輯讀數量

Innodb_buffer_pool_wait_free --一般情況，通過後臺向InnoDB緩衝池寫。但是，如果需要讀或創建頁，並且沒有乾淨的頁可用，則它還 需要先等待頁面清空。該計數器對等待實例進行記數。如果已經適當設置緩衝池大小，該值應小。

Innodb_buffer_pool_write_requests --向InnoDB緩衝池的寫數量

六，Mysql 之Innodb_data

Innodb_data_fsyncs --fsync()操作數

Innodb_data_pending_fsyncs --當前掛起的fsync()操作數

Innodb_data_pending_reads --當前掛起的讀數

Innodb_data_pending_writes --當前掛起的寫數

Innodb_data_read --至此已經讀取的數據數量（字節）

Innodb_data_reads --數據讀總數量

Innodb_data_writes --數據寫總數量

Innodb_data_written --至此已經寫入的數據量（字節）

Innodb_dblwr_pages_written --已經執行的雙寫操作數量

Innodb_dblwr_writes --雙寫操作已經寫好的頁數

七，Mysql 之 innodb_log

Innodb_log_waits --我們必須等待的時間，因爲日誌緩衝區太小，我們在繼續前必須先等待對它清空

Innodb_log_write_requests --日誌寫請求數

Innodb_log_writes --向日志文件的物理寫數量

Innodb_os_log_fsyncs --向日志文件完成的fsync()寫數量

Innodb_os_log_pending_fsyncs --掛起的日誌文件fsync()操作數量

Innodb_os_log_pending_writes --掛起的日誌文件寫操作

Innodb_os_log_written --寫入日誌文件的字節數

八，Mysql 之 Innodb_page

Innodb_page_size --編譯的InnoDB頁大小(默認16KB)。 許多值用頁來記數；頁的大小很容易轉換爲字節

Innodb_pages_created --創建的頁數

Innodb_pages_read --讀取的頁數

Innodb_pages_written --寫入的頁數

九，Mysql 之 Innodb_row_lock

Innodb_row_lock_current_waits --當前等待的待鎖定的行數

innodb_row_lock_time --行鎖定花費的總時間，單位毫秒

Innodb_row_lock_time_avg --行鎖定的平均時間，單位毫秒

Innodb_row_lock_time_max --行鎖定的最長時間，單位毫秒

Innodb_row_lock_waits --一行鎖定必須等待的時間數

Innodb_rows_deleted --從InnoDB表刪除的行數

Innodb_rows_inserted --插入到InnoDB表的行數

Innodb_rows_read --從InnoDB表讀取的行數

Innodb_rows_updated --InnoDB表內更新的行數

十，Mysql 之 查詢

Queries --服務器執行的請求個數，包含存儲過程中的請求

Questions --已經發送給服務器的查詢的個數

Qcache_free_blocks --查詢緩存內自由內存塊的數量

Qcache_free_memory --用於查詢緩存的自由內存的數量

Qcache_hits --查詢緩存被訪問的次數

Qcache_inserts --加入到緩存的查詢數量

Qcache_lowmem_prunes --由於內存較少從緩存刪除的查詢數量

Qcache_not_cached --非緩存查詢數(不可緩存，或由於query_cache_type設 定值未緩存)

Qcache_queries_in_cache --登記到緩存內的查詢的數量

Qcache_total_blocks --查詢緩存內的總塊數

十一，Mysql 之 Slave

Slave_heartbeat_period --複製的心跳間隔

Slave_open_temp_tables --服務器打開的臨時表數量

Slave_received_heartbeats --從服務器心跳數

Slave_retried_transactions --本次啓動以來從服務器複製線程重試次數

Slave_running --如果該服務器是連接到主服務器的從服務器，則該值爲ON

十二，Mysql 之operations

Com_select --每秒查詢

Com_update --每秒更新

Com_insert --每秒插入

Com_commit --每秒提交

Com_delete --每秒刪除

Com_begin --每秒開始操作

Com_rollback --每秒回滾

十三，Mysql 之 帶寬

Bytes_received --接收字節

Bytes_sent --返回字節