1、Max Connections和Max Used Connection
這兩個就不細說了，分別是最大鏈接數限制和每個用戶最大鏈接數限制。
2、Aborted Clients：
The number of connections that were aborted because the client died without closing the connection properly.
當ablort clients增大的時候意味着有客戶端成功建立連接，但是很快就斷開連接或者被終止了，這種情況一般發生在網絡不穩定的環境中。主要的可能性有
a）客戶端沒有主動關閉mysql連接mysql_close()。
b）wait_timeout設置很短被mysql幹掉了。
c）客戶端由於某些原因被幹掉了。
3、Aborted Connection：
The number of failed attempts to connect to the MySQL server.
當有大量的鏈接連接不上mysql的時候，這個數值就會激增。主要的可能有：
a）沒有授權或者密碼不對。一般錯誤日誌中會有如下報錯（Access denied for ‘user’@‘host’）
b）連接數滿了。一般報錯包含（too many connections）
c）超過鏈接時間限制，主要有這個參數控制connect_timeout（mysql默認是10s，基本除非網絡環境極端不好，一般不會超時。）
4、Threads Connected：
The number of currently open connections.
也就是我們經常使用show processlist看見那個數值。
5、Connections
The number of connection attempts (successful or not) to the MySQL server.
所有嘗試連接到mysql server的連接數，關鍵時不管成功還是失敗。所以這個數值的增量並不等於show processlist的數值，這點需要注意。
瞭解以上參數之後，就可以分析這個圖了，首先第一反應時連接數有增加，我們可以看到connections和thread connected都增加了，但是沒有達到max connections的限制。
在仔細看圖下的數據，我們發現abort connection和connections的max值和avg值基本一樣，在仔細看圖，可以發現藍線和綠線基本重合了。
從上述參數含義看，在問題時間段所有嘗試建立的鏈接都失敗了，導致connections和abort connection同步增加完全重疊。
但是究竟是什麼導致鏈接數上升，前端開始重建鏈接，由於當時的前端日誌沒有及時分析出來，故我們就不得而知了。但是有3個懷疑點：
1、由於mysql版本是5.5.12，所以可能遇到了max_connections的bug，可以見這個blog（http://www.cnblogs.com/billyxp/p/3408335.html），這種情況下，前端日誌應該有非常多的too many connection是的報錯。
2、短時間內有大量的大包傳輸，導致超過max_allow_packet的限制，導致斷開連接。這個設置在server和client上都有，需要同步配置。同時前端應該報Got a packet bigger than ‘max_allowedpacket’ bytes這個報錯。
3、超過max_connect_error的限制，導致某一個ip出現問題，不停的重試。（這個可能是最不可能，首先默認數值非常大，其次單個ip不應該出現這麼大的影響。max_connect_error代表某一個ip連續失敗超過n之後，server會拒絕這個ip的請求，只有flush host cache纔可以解封。）
Binlog_cache_disk_use （事務類）二進志日誌緩存的已經存在硬盤的條數
Binlog_cache_use （事務類）二進制日誌已緩存的條數（內存中） 注意，這個不是容量，而是事務個數。每次有一條事務提交，都會有一次增加
Binlog_stmt_cache_disk_use （非事務類）二進志日誌緩存的已經存在硬盤的條數
Binlog_stmt_cache_use （非事務類）二進制日誌已緩存的條數（內存中） 非事務型的語句，都存在這兒，比如MYISAM引擎的表，插入記錄就存在這兒
Uptime_since_flush_status --最近一次使用FLUSH STATUS 的時間（以秒爲單位）
Uptime --服務器已經運行的時間（以秒爲單位）
Threads_running --激活的（非睡眠狀態）線程數。
Threads_created --創建用來處理連接的線程數。如果Threads_created較大，你可能要增加thread_cache_size值。 緩存訪問率的計算方法Threads_created/Connections。
Threads_connected --當前打開的連接的數量。
Threads_cached --線程緩存內的線程的數量
Table_locks_immediate表示立即釋放表鎖數，Table_locks_waited表示需要等待的表鎖數，
如果Table_locks_immediate / Table_locks_waited > 5000，最好採用InnoDB引擎，
因爲InnoDB是行鎖而MyISAM是表鎖，對於高併發寫入的應用InnoDB效果會好些。
示例中的服務器Table_locks_immediate / Table_locks_waited ＝ 235，MyISAM就足夠了。
show global status like 'Table_open_cache_misses'; # 新打開的表的次數。 不命中
show global status like 'Table_open_cache_hits'; # 從表緩存中拿已打開的表的次數，該狀態變量 5.6 纔開始存在 命中
show global status like 'Opened_tables'; # 打開表的總次數
通過已知自己數據庫中有多少表，再觀察 Opened_tables 的值，可以得知表緩存的數量是否合理，如果打開表的次數大於數據庫中已有的表數
量，則表示 table_open_cache 的值不夠，可以考慮加大。
計算表緩存的命中率：
select concat(Table_open_cache_hits /(Table_open_cache_misses + Table_open_cache_hits) * 100,’%’);
通過計算表緩存的命中率，可反映出表緩存的情況，該比例越大越好
1 讀寫比例：
show global status like 'com_select'; 獲得服務器啓動到目前查詢操作執行的次數；
show global status like 'com_insert'; 獲得服務器啓動到目前插入操作執行的次數；
show global status like 'com_update'; 獲得服務器啓動到目前更新操作執行的次數；
show global status like 'com_delete’; 獲得服務器啓動到目前刪除操作執行的次數；
計算讀百分比：
select concat(com_select / (com_select+com_insert+com_update+com_delete) 100,'%');
計算寫百分比：
select concat(com_insert+com_update+com_delete / (com_select+com_insert+com_update+com_delete) 100,’%’);
通過檢查數據庫讀寫比例，可反映出應用是讀密集型還是寫密集型。
2 慢查詢比例：
開啓慢查詢日誌：
slow_query_log = 1 # 開啓慢查詢日誌
log_output = FILE|TABLE # 指定日誌存儲方式，默認爲 file
slow_query_log_file = slow-query.log # 指定慢查詢日誌文件位置
long_query_time = 1 # 執行及響應時間超過該參數設置的值記錄日誌
show global status like 'Slow_queries '; # 獲得服務器啓動到目前慢查詢操作記錄的次數；
注意，慢查詢包括 select 、 update 以及 delete ，沒有 insert 。
計算慢查詢比例：
select concat(Slow_queries / (Com_select+Com_update+Com_delete) * 100,’%’);
通過計算慢查詢比例，可反映出數據庫運行效能。
3 連接數檢查：
show global status like 'max_connections'; # 獲得數據庫運行的最大連接數 //允許的最大連接數
show global status like 'Max_used_connections'; # 獲得最大一次的連接數 //最大突發並行連接數
show global status like 'connections'; # 獲得數據庫運行到目前，總共被連接了多少次 //登陸的次數
show global status like 'Threads_connected'; # 獲得當前連接數
show global status like 'Threads_running'; # 獲得當前正在運行的連接數
mysql> show global status like 'Threads_connected'; //兩次 mysql -uroot -p +-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_connected | 2 |
+-------------------+-------+1 row in set (0.01 sec)
mysql> show global status like 'Threads_running'; +-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| Threads_running | 1 |
+-----------------+-------+1 row in set (0.00 sec)
mysql> show processlist;+----+------+-----------+-------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------+-------+---------+------+-------+------------------+
| 2 | root | localhost | mysql | Sleep | 4 | | NULL |
| 3 | root | localhost | test | Query | 0 | init | show processlist |
+----+------+-----------+-------+---------+------+-------+------------------+2 rows in set (0.00 sec)
計算當前連接數的比例：
select concat(Threads_connected / max_connections 100,'%'); # 計算最大一次的連接數比例：
select concat(Max_used_connections / max_connections 100,'%');# 通過連接數檢查，可得知數據庫在不同時間段被請求的壓力
4 線程緩存：
show global status like 'Connections'; # 獲得數據庫運行到目前，總共被連接了多少次
show global status like 'Threads_created'; # 獲得數據庫運行到目前，創建連接線程的次數
計算連接線程緩存命中率：
select concat((Connections-Threads_created) / Connections × 100,’%’);
通過計算連接線程緩存命中率，可反映出連接線程的命中情況，命中率越大越好。
如果命中率過低，則表示緩存連接線程的數量過少，可以考慮加大 thread_cache_size 的值。
5 表緩存：
show global status like 'Table_open_cache_misses'; # 新打開的表的次數。 不命中
show global status like 'Table_open_cache_hits'; # 從表緩存中拿已打開的表的次數，該狀態變量 5.6 纔開始存在 命中
show global status like 'Opened_tables'; # 打開表的總次數
通過已知自己數據庫中有多少表，再觀察 Opened_tables 的值，可以得知表緩存的數量是否合理，如果打開表的次數大於數據庫中已有的表數
量，則表示 table_open_cache 的值不夠，可以考慮加大。
計算表緩存的命中率：
select concat(Table_open_cache_hits /(Table_open_cache_misses + Table_open_cache_hits) * 100,’%’);
通過計算表緩存的命中率，可反映出表緩存的情況，該比例越大越好
mysql> create table ttt (a int);
Query OK, 0 rows affected (0.22 sec)
mysql> show global status like 'Table_open_cache_hits';+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Table_open_cache_hits | 31 |
+-----------------------+-------+1 row in set (0.00 sec)
mysql> show global status like 'Table_open_cache_misses';+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Table_open_cache_misses | 116 |
+-------------------------+-------+1 row in set (0.00 sec)
mysql> show global status like 'Opened_tables';+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Opened_tables | 116 |
+---------------+-------+1 row in set (0.00 sec)
mysql> select * from ttt; //第一次打開
Empty set (0.01 sec)
mysql> show global status like 'Opened_tables'; //+1+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Opened_tables | 117 |
+---------------+-------+1 row in set (0.02 sec)
mysql> show global status like 'Table_open_cache_misses'; //table緩存中沒有表，丟失 +1+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Table_open_cache_misses | 117 |
+-------------------------+-------+1 row in set (0.01 sec)
mysql> show global status like 'Table_open_cache_hits'; //緩存未命中,不變+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Table_open_cache_hits | 31 |
+-----------------------+-------+1 row in set (0.01 sec)
mysql> select * from ttt; //在打開表
Empty set (0.00 sec)
mysql> show global status like 'Table_open_cache_hits'; //表緩存命中+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Table_open_cache_hits | 32 |
+-----------------------+-------+1 row in set (0.01 sec)
6 臨時表：
show global status like 'Created_tmp_disk_tables'; # 查看在磁盤上創建臨時表的次數
show global status like 'Created_tmp_tables'; # 查看創建臨時表的總次數，包括在內存中和磁盤。
如果發現在磁盤上創建臨時表的次數過多，則表示臨時表的緩存區內存不夠，可以考慮加大 tmp_table_size 和 max_heap_table_size 的值。
計算在磁盤上創建臨時表的比例：
select concat(Created_tmp_disk_tables / Created_tmp_tables * 100,’%’);
通過計算在磁盤上創建臨時表的比例，可反映出數據庫的使用臨時表的情況，該比例越小越好。
7 額外的排序：
show global status like 'Sort_merge_passes'; # 在磁盤中進行額外排序的次數
show global status like 'Sort_scan'; # 通過表掃描進行排序的總次數，也就是額外排序的總次數
如果發現在磁盤上進行排序的次數過多，則表示排序緩衝區內存不夠，可以考慮加大 sort_buffer_size 的值。
計算磁盤排序的比例：
select concat(Sort_merge_passes / Sort_scan * 100,'%');
通過計算在磁盤上進行額外排序的比例，可反映出數據庫排序的情況，該比例越小越好。
8 binlog 緩衝：
show global status like 'Binlog_cache_disk_use'; # 在磁盤上創建臨時文件用於保存 binlog 的次數
show global status like 'Binlog_cache_use'; # 緩衝 binlog 的總次數，包括 binlog 緩衝區和在磁盤上創建臨時文件保存 binlog 的總次數
如果發現在磁盤上創建臨時文件保存 binlog 的次數過多，則表示 binlog 緩衝區內存不夠，可以考慮加大 binlog_cache_size 的值。
計算在磁盤上創建臨時文件保存 binlog 的比例：
select concat(Binlog_cache_disk_use / Binlog_cache_use * 100,’%’);
通過計算在磁盤上創建臨時文件保 binlog 的比例，可反映出數據庫 binlog 的情況，該比例越小越好。
9 redo 日誌：
select global status like 'Innodb_log_waits'; # 查看 innodb redo 日誌等待緩衝區刷新的次數。
當 redo 緩衝區容納不下事務產生的 redo 日誌時，本次事務產生的 redo 日誌在寫入 redo 緩衝區之前就必須等待 redo 緩衝區有足夠的空間才能寫入。
如果發現 redo 日誌等待刷新的次數過多，則表示 innodb redo 日誌緩衝區的大小不夠，可以考慮加大 innodb_log_buffer_size 的值。
10 InnoDB 緩存：
show global status like 'Innodb_buffer_pool_read_requests'; # 讀取頁的總次數
show global status like 'Innodb_buffer_pool_read'; # 從磁盤讀取頁的次數
如果發現從磁盤讀取頁的次數過多，則有可能是因爲 innodb 緩衝池的大小不夠，此時可以考慮加到 innodb_buffer_pool_size 的值。
計算 innodb 緩存命中率：
select concat((Innodb_buffer_pool_read_requests - Innodb_buffer_pool_read) / Innodb_buffer_pool_read_requests * 100,’%’);
通過計算 innodb 緩存命中率，可反映出 innodb 緩存的效率，該比例越大越好
| Innodb_buffer_pool_pages_data | 496 |包含數據的頁數(髒或乾淨)。
| Innodb_buffer_pool_pages_dirty | 5 |當前的髒頁數
| Innodb_buffer_pool_pages_flushed | 1182773 |已經flush的頁面數
| Innodb_buffer_pool_pages_free | 0 |空頁數
| Innodb_buffer_pool_pages_misc | 16 |優先用作管理的頁數
| Innodb_buffer_pool_pages_total | 512 |總頁數
| Innodb_buffer_pool_read_ahead_rnd | 515979 |隨機預讀的次數(讀大部分數據時)
| Innodb_buffer_pool_read_ahead_seq | 3408867 |順序預讀的次數(全表掃描時)
| Innodb_buffer_pool_read_requests | 10760142502 |InnoDB已經完成的邏輯讀請求數
| Innodb_buffer_pool_reads | 6912521 |從磁盤上一頁一頁的讀取的頁數，從緩衝池中讀取頁面， 但緩衝池裏面沒有， 就會從磁盤讀取
| Innodb_buffer_pool_wait_free | 0 |緩衝池等待空閒頁的次數， 當需要空閒塊而系統中沒有時， 就會等待空閒頁面
| Innodb_buffer_pool_write_requests | 8136890 |緩衝池總共發出的寫請求次數
| Innodb_data_fsyncs | 1457304 |fsync()操作數
| Innodb_data_pending_fsyncs | 0 |innodb當前等待的fsync次數
| Innodb_data_pending_reads | 0 |innodb當前等待的讀的次數
| Innodb_data_pending_writes | 0 |innodb當前等待的寫的次數
| Innodb_data_read | 1009745694720 |總共讀入的字節數
| Innodb_data_reads | 11756800 |innodb完成的讀的次數
| Innodb_data_writes | 2308122 |innodb完成的寫的次數
| Innodb_data_written | 40737600000 | 總共寫出的字節數
| Innodb_dblwr_pages_written | 1182773 |雙寫已經寫好的頁數
| Innodb_dblwr_writes | 76828 |已經執行的雙寫操作數量
| Innodb_log_waits | 10 |因爲日誌緩衝區太小，我們在繼續前必須先等待對它清空
| Innodb_log_write_requests | 2979109 |日誌寫請求數
| Innodb_log_writes | 1252587 |向日志文件的物理寫數量
| Innodb_os_log_fsyncs | 1304054 |向日志文件完成的fsync()寫數量
| Innodb_os_log_pending_fsyncs | 0 |掛起的日誌文件fsync()操作數量。
| Innodb_os_log_pending_writes | 0 |掛起的日誌文件寫操作。
| Innodb_os_log_written | 1954254848 |寫入日誌文件的字節數
| Innodb_page_size | 16384 |編譯的InnoDB頁大小(默認16KB)
| Innodb_pages_created | 58540 |創建的頁數
| Innodb_pages_read | 61630057 |從buffer_pool中讀取的頁數
| Innodb_pages_written | 1182773 |寫入的頁數
| Innodb_row_lock_current_waits | 0 |當前等待的待鎖定的行數
| Innodb_row_lock_time | 595899 |行鎖定花費的總時間，單位毫秒
| Innodb_row_lock_time_avg | 54 |行鎖定的平均時間
| Innodb_row_lock_time_max | 7241 |行鎖定的最長時間
| Innodb_row_lock_waits | 11032 |一行鎖定必須等待的時間數
| Innodb_rows_deleted | 7199 |刪除
| Innodb_rows_inserted | 736893 |插入
| Innodb_rows_read | 10400853035 |從InnoDB表讀取的行數
| Innodb_rows_updated | 932768 |更新**