你真的了解 MySQL 數據庫的運行狀況嗎？

jopen 8年前發布 | 14K 次閱讀 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&gt;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

參考文章：

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

來自： http://www.ituring.com.cn/article/210697

 本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！