你真的瞭解 MySQL 數據庫的運行情況嗎？

2015年第三方市場調查機構 Evans 數據公司最近公佈的一系列客戶調查數據顯示，在過去兩年裏，MySQL 在全部開發者使用的數據庫中得到了25%的市場份額，Evans 公司的本次調查顯示，數據庫的使用者中有40%是開發人員，而兩年前這一數據是32%。

此外 MySQL 愈來愈被企業級所接受，現在數據日益膨脹，應用愈來愈普遍，隨之而來的 MySQL 性能分析，監控告警，集成可視化的討論也愈來愈多了，還有利用各類工具對 MySQL 各指標數據進行分析的文章也曾出不窮，今天本文就幾個須要注意的重點指標總結一下。

InnoDB 緩衝池

InnoDB 引擎在內存中有一個緩衝池用於緩存數據和索引，這有助於你更快地執行 MySQL 查詢語句。選擇合適的內存大小須要一些重要的決策並對系統的內存消耗有較多的認識，你須要考慮：

• 其它的進程須要消耗多少內存。這包括你的系統進程，頁表，套接字緩衝。
• 你的服務器是否專門用於 MySQL 仍是你運行着其它很是消耗內存的服務。

在一個專用的機器上，你可能會把 60-70％ 的內存分配給 innodb_buffer_pool_size，若是你打算在一個機器上運行更多的服務，你應該從新考慮專門用於 innodb_buffer_pool_size 的內存大小，此時須要關注一下幾個指標，InnoDB 緩衝池可用頁面的數量，使用了多少，總計多少，以及緩衝池的使用率。經過這些指標數據判斷數據庫的健康情況以及調節內存。

• mysql.innodb.buffer_pool_free
• mysql.innodb.buffer_pool_total
• mysql.innodb.buffer_pool_used
• mysql.innodb.buffer_pool_utilization

MySQL 進程數，最大鏈接數

threads_connected 當前客戶端已鏈接的數量。這個值會少於預設的值，但你也會監控到這個值較大，它可保證客戶端是處在活躍狀態。若是 threads_connected == max_connections 時，數據庫系統就不能提供更多的鏈接數了，這時，若是程序還想新建鏈接線程，數據庫系統就會拒絕，若是程序沒作過多的錯誤處理，就會出現報錯信息。

threads_running 處於激活狀態的線程的個數，若是數據庫超負荷了，你將會獲得一個正在（查詢的語句持續）增加的數值。這個值也能夠少於預先設定的值。這個值在很短的時間內超過限定值是沒問題的。當 threads_running 值超過預設值時而且該值在5秒內沒有回落時，要同時監視其餘的一些值。

max_connections 當前服務器容許多少併發鏈接。MySQL 服務器容許有 SUPER 權限的用戶在最大鏈接以外再創建一個鏈接。只有當執行 MySQL 請求的時候纔會創建鏈接，執行完成後會關閉鏈接並被新的鏈接取代。

但要記住，過多的鏈接會致使內存的使用量太高而且會鎖住你的 MySQL 服務器。通常小網站須要 100-200 的鏈接數，而較大可能須要 500-800 甚至更多。此值很大程度上取決於你 MySQL 的使用狀況。一下指標代表服務器當前鏈接數以及最大鏈接數，

• mysql.threads_connected
• mysql.threads_running
• mysql.net.max_connections

MySQL 臨時表和內存表

臨時表可使用任何存儲引擎，臨時表只在單個鏈接中可見，當鏈接斷開時，臨時表也會消失。MySQL 最初會將臨時表建立在內存中，當數據變的太大後，就會轉儲到磁盤上。內存表是指用 MEMORY 引擎建立的表。表結構存在於磁盤，數據放在內存中。

若是起初在內存中建立的臨時表變的太大，MySQL會自動將其轉成磁盤上的臨時表。內存中的臨時表由 tmp_table_size 和 max_heap_table_size 兩個參數決定，這與建立 MEMORY 引擎的表不一樣。MEMORY 引擎的表由 max_heap_table_size 參數決定表的大小，而且它不會轉成到在磁盤上的格式。

每次建立臨時表（包括內存上和磁盤上），created_tmp_tables 都會增長，若是是在磁盤上建立臨時表（包括從內存上轉成磁盤的），created_tmp_disk_tables 也會增長，created_tmp_files 表示 MySQL 服務建立的臨時文件文件數，比較理想的配置是： created_tmp_disk_tables / created_tmp_tables * 100% <= 25%

• mysql.performance.created_tmp_disk_tables
• mysql.performance.created_tmp_files
• mysql.performance.created_tmp_tables

MySQL 查詢

數據庫是很容易產生瓶頸的地方，其中最影響速度的就是那些查詢很是慢的語句，這些慢查詢語句，多是寫的不夠合理或者是大數據下多表的聯合查詢等等，因此要重點監控找出這些語句並進行優化。

• mysql.performance.queries
• mysql.performance.questions
• mysql.performance.slow_queries

queries 由服務器執行的語句的數目，該變量包括存儲程序中執行的語句，不像 questions 變量。它不包含 COM_PING 和 COM_STATISTICS 命令。這個變量添加近 MySQL 5.0.76版本中。

questions 由服務器執行的語句的數目，如在 MySQL 5.0.72版本，它包括由客戶機發送到服務器的執行狀態，再也不包含存儲程序中執行語句，不一樣於 queries 變量。這個變量不包含 COM_PING，COM_STATISTICS，COM_STMT_PREPARE，COM_STMT_CLOSE，和 COM_STMT_RESET 等命令。

queries 是一個全局性狀態變量，而 questions 是一個會話，能夠用來看看有多少會話經過當前鏈接發到服務器。queries 速度上升和降低都是正常的，它不是一個固定閾值的指標。但須要注意的是若是其數值發生急劇降低等忽然變化，那就可能出現了嚴重問題。

slow_queries：查詢時間超過 long_query_time 時間的數量，如何定義一個慢查詢取決於數據庫的使用狀況和性能要求。但總之若是慢查詢的數量很高，那你須要記錄慢查詢來定位數據庫中的問題並進行調試。能夠經過在你的 MySQL 配置文件中添加如下值來啓用：

slow-query-log = 1
slow-query-log-file = /var/lib/mysql/mysql-slow.log
long_query_time = 1

第一個變量啓用慢查詢日誌，第二個指定 MySQL 實際的日誌文件存儲位置。使用 long_query_time 來定義完成 MySQL 查詢多少用時算長。

MySQL 的查詢緩存

若是你有不少重複的查詢而且數據不常常改變那建議使用緩存查詢。人們常常不理解 query_cache_size的實際含義而將它設置爲 GB 級，但這樣設置實際上會下降服務器的性能。

緣由是在更新過程當中線程須要鎖定緩存。一般設置爲 200-300 MB應該足夠了。若是你的網站比較小的，你能夠嘗試給 64M 並在之後須要時及時增長。如下指標是查詢緩存命中率，鍵緩存利用率：

• mysql.performance.qcache_hits
• mysql.performance.key_cache_utilization

MySQL 主從複製

說了那麼多，還有一個很重要的 MySQL 主從複製，主從複製的好處不用多說：採用主從服務器這種架構，穩定性得以提高。若是主服務器發生故障，可使用從服務器來提供服務。在主從服務器上分開處理用戶的請求，能夠提高數據處理效率。將主服務器上的數據複製到從服務器上，保護數據免受意外的損失等等。其鏈接狀態能夠經過下面命令查看：

mysql>SHOW SLAVE STATUS\G；

在 Master 與 Slave 之間完成一個異步的複製過程須要由三個線程來完成，其中兩個線程（ Sql 線程和 IO 線程）在 Slave 端，另一個線程（ IO 線程）在 Master 端。Slave_IO_Running 和 Slave_SQL_Running 兩列的值都爲 "Yes"，這代表 Slave 的 I/O 和 SQL 線程都在正常運行，主從同步功能也就是正常的。

• mysql.replication.slave_io_running
• mysql.replication.slave_sql_running
• mysql.replication.last_io_errno
• mysql.replication.last_sql_errno

Cloud Insight 可視化監控

說了那麼多 MySQL 查詢，緩衝，鏈接數，內存表臨時表，主從複製，如今回到主題上，你瞭解本身 MySQL 數據庫的運行情況嗎，如今有使用什麼監控工具，是否能夠實時可視化監控，是否須要專人來進行配置，是否能夠內網部署監控，是否能夠對每一個指標設置報警策略？若是想體驗擁有以上功能的監控工具，那必然要試試 Cloud Insight ，必定不會讓您失望，它支持 MySQL 以上全部指標，更多指標參考 Cloud Insight MySQL 監控，其實也沒什麼大不了的功能，無非是：

• 安裝上便可實時監控數據庫指標數據
• 探針一鍵安裝（大概14s），簡單部署（有的只需複製一份配置文件）
• 支持內網部署
• 可針對每一個指標設置報警策略

最後再貼個圖，隨意放幾個指標數據：

好啦，說完了撤啦 Y(^_^)Y

參考文章：

• MySQL內存表和臨時表的看法
• 15 個有用的 MySQL/MariaDB 性能調整和優化技巧
• MySQL 指標詳解

Cloud Insight 集監控、管理、計算、協做、可視化於一身，幫助全部 IT 公司，減小在系統監控上的人力和時間成本投入，讓運維工做更加高效、簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。 本文轉自 OneAPM 官方博客