MySQL 性能監控4大指標——第一部分

時間 2019-11-16

標籤 mysql 性能監控指標第一部分欄目 MySQL 简体版

原文原文鏈接

【編者按】本文做者爲 John Matson，主要介紹 mysql 性能監控應該關注的4大指標。第一部分將詳細介紹前兩個指標：查詢吞吐量與查詢執行性能。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。html

MySQL 是什麼？

MySQL 是現而今最流行的開源關係型數據庫服務器。由 Oracle 全部，MySQL 提供了能夠免費下載的社區版及包含更多特性與支持的商業版。從1995年首發以來，MySQL 衍生出多款備受矚目的分支，諸如具備至關競爭力的 MariaDB 及 Percona。mysql

關鍵 MySQL 統計指標

若是你的數據庫運行緩慢，或者出於某種緣由沒法響應查詢，技術棧中每一個依賴數據庫的組件都會遭受性能問題。爲了保證數據庫的平穩運行，你能夠主動監控如下四個與性能及資源利用率相關的指標：git

查詢吞吐量github
查詢執行性能sql
鏈接狀況數據庫
緩衝池使用狀況編程

MySQL 用戶能夠接觸到數百個數據庫指標，所以，在本文中，筆者將專一於能幫助咱們實時瞭解數據庫健康與性能的關鍵指標。緩存

本文參考了咱們在監控入門系列文章中介紹的指標術語，後者爲指標收集與告警提供了基礎框架。服務器

不一樣版本與技術的兼容性網絡

本系列文章討論的一些監控策略只適用於 MySQL 5.6與5.7版本。這些版本間的差別將在後文中說起。

本文列出的大多數指標與監控策略一樣適用於與 MySQL 兼容的技術，諸如 MariaDB 與 Percona 服務器，不過帶有一些明顯的差異。例如，MySQL Workbench(工做臺)中的一些特性（在本系列第二篇中有詳細介紹）就與當下的一些 MariaDB 版本不兼容。

Amazon RDS 用戶應該查看咱們專門製做的 MySQL 在 RDS 以及與 MySQL 兼容的 Amazon Aurora 監控手冊。

查詢吞吐量

名稱	描述	指標類型	可用性
Questions	已執行語句（由客戶端發出）計數	Work：吞吐量	服務器狀態變量
Com_select	SELECT 語句	Work：吞吐量	服務器狀態變量
Writes	插入，更新或刪除	Work：吞吐量	根據服務器狀態變量計算獲得

在監控任何系統時，你最關心的應該是確保系統可以高效地完成工做。數據庫的工做是運行查詢，所以在本例中，你的首要任務是確保 MySQL 可以如期執行查詢。

MySQL 有一個名爲 Questions 的內部計數器（根據 MySQL 用語，這是一個服務器狀態變量），客戶端每發送一個查詢語句，其值就會加一。由 Questions 指標帶來的以客戶端爲中心的視角經常比相關的 Queries 計數器更容易解釋。做爲存儲程序的一部分，後者也會計算已執行語句的數量，以及諸如 PREPARE 和 DEALLOCATE PREPARE 指令運行的次數，做爲服務器端預處理語句的一部分。

經過如下指令，查詢諸如 Questions 或 Com_select 服務器狀態變量的值：

SHOW GLOBAL STATUS LIKE "Questions";
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Questions     | 254408 |
+---------------+--------+

你也能夠監控讀、寫指令的分解狀況，從而更好地理解數據庫的工做負載、找到可能的瓶頸。一般，讀取查詢會由 Com_select 指標抓取，而寫入查詢則可能增長三個狀態變量中某一個的值，這取決於具體的指令：

Writes = Com_insert + Com_update + Com_delete

應該設置告警的指標：Questions

當前的查詢速率一般會有起伏，所以，若是基於固定的臨界值，查詢速率經常不是一個可操做的指標。可是，對於查詢數量的突變設置告警很是重要——尤爲是查詢量的驟降，可能暗示着某個嚴重的問題。

查詢性能

名稱	描述	指標類型	可用性
查詢運行時間	每種模式下的平均運行時間	Work：性能	性能模式查詢
查詢錯誤	出現錯誤的 SQL 語句數量	Work：錯誤	性能模式查詢
Slow_queries	超過可配置的`long_query_time` 限制的查詢數量	Work：性能	服務器狀態變量

MySQL 用戶監控查詢延遲的方式有不少，既能夠經過 MySQL 內置的指標，也能夠經過查詢性能模式。從 MySQL 5.6.6 版本開始默認啓用，MySQL 的 performance_schema 數據庫中的表格存儲着服務器事件與查詢執行的低水平統計數據。

性能模式語句摘要

性能模式的 events_statements_summary_by_digest 表格中保存着許多關鍵指標，抓取了與每條標準化語句有關的延遲、錯誤和查詢量信息。從該表截取的一行樣例顯示，某條語句被執行了兩次，平均執行用時爲 325 毫秒（全部計時器的測量值都以微微秒爲單位）：

*************************** 1. row *************************** 
               SCHEMA_NAME: employees                     
                    DIGEST: 0c6318da9de53353a3a1bacea70b4fce                
               DIGEST_TEXT: SELECT * FROM `employees` WHERE `emp_no` > ? 
                COUNT_STAR: 2             
            SUM_TIMER_WAIT: 650358383000             
            MIN_TIMER_WAIT: 292045159000             
            AVG_TIMER_WAIT: 325179191000             
            MAX_TIMER_WAIT: 358313224000              
             SUM_LOCK_TIME: 520000000                 
                SUM_ERRORS: 0               
              SUM_WARNINGS: 0         
         SUM_ROWS_AFFECTED: 0              
             SUM_ROWS_SENT: 520048          
          SUM_ROWS_EXAMINED: 520048
          ...          
          
          SUM_NO_INDEX_USED: 0     
     SUM_NO_GOOD_INDEX_USED: 0                 
                 FIRST_SEEN: 2016-03-24 14:25:32                  
                  LAST_SEEN: 2016-03-24 14:25:55

摘要表會標準化全部語句（如上面的 DIGEST_TEXT 一欄所示），忽略數據值，規範化空格與大小寫，所以，下面的兩條查詢會被認爲是相同的：

select * from employees where emp_no >200;SELECT * FROM employees WHERE emp_no > 80000;

想要按模式抽取出以微秒爲單位的平均運行時間，你能夠這樣查詢性能模式：

SELECT schema_name
     , SUM(count_star) count     
     , ROUND(   (SUM(sum_timer_wait) / SUM(count_star))              
     / 1000000) AS avg_microsec  
     
     FROM performance_schema.events_statements_summary_by_digest 
     
 WHERE schema_name IS NOT NULL 
 GROUP BY schema_name;
+--------------------+-------+--------------+
| schema_name        | count | avg_microsec |
+--------------------+-------+--------------+
| employees          |   223 |       171940 |
| performance_schema |    37 |        20761 |
| sys                |     4 |          748 |
+--------------------+-------+--------------+

類似地，按模式計算出現錯誤的語句總數，能夠這麼作：

SELECT schema_name
     , SUM(sum_errors) err_count
  FROM performance_schema.events_statements_summary_by_digest 
  WHERE schema_name IS NOT NULL 
  GROUP BY schema_name;
+--------------------+-----------+
| schema_name        | err_count |
+--------------------+-----------+
| employees          |         8 |
| performance_schema |         1 |
| sys                |         3 |
+--------------------+-----------+

sys 模式

用上面的方式查詢性能模式能以編程方式有效地從數據庫中檢索出指標。然而，對於特別查詢或調查，使用 MySQL 的 sys 模式一般更爲簡單。sys 模式以人們更易讀的格式提供了一個有條理的指標集合，使得對應的查詢更加簡單。例如，想要找出最慢的語句（運行時間在95名開外）：

SELECT * FROM sys.statements_with_runtimes_in_95th_percentile;

或者查看哪些標準化語句出現了錯誤：

SELECT * FROM sys.statements_with_errors_or_warnings;

在 sys 模式的文檔中，詳細介紹了許多有用的例子。sys 模式在 MySQL 5.7.7 版本中是默認包含的。不過，MySQL 5.6 用戶經過簡單的幾個指令就能安裝它。

慢查詢

除了性能模式與 sys 模式中豐富的性能數據，MySQL 還提供了一個 Slow_queries 計數器，每當查詢的執行時間超過 long_query_time 參數指定的值以後，該計數器就會增長。默認狀況下，該臨界值設置爲10秒。

SHOW VARIABLES LIKE 'long_query_time';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+

long_query_time 參數的值可經過一條指令進行調整。例如，將慢查詢臨界值設置爲5秒：

SET GLOBAL long_query_time = 5;

（請注意，你可能要關閉會話，再從新鏈接至數據庫，這些更改才能在會話層生效。）

調查查詢性能問題

若是你的查詢運行得比預期要慢，極可能是某條最近修改的查詢在搗鬼。若是沒有發現特別緩慢的查詢，接下來就該評估系統級指標，尋找核心資源（CPU，磁盤 I/O，內存以及網絡）的限制。CPU 飽和與 I/O 瓶頸是常見的問題根源。你可能還想檢查 Innodb_row_lock_waits 指標，該指標記錄着 InnoDB 存儲引擎不得不停下來得到某行的鎖定的次數。從 MySQL 5.5 版本起，InnoDB 就是默認的存儲引擎，MySQL 對 InnoDB 表使用行級鎖定。

爲了提升讀取與寫入操做的速度，許多用戶會想經過調整 InnoDB 使用的緩衝池大小來緩存表與索引數據。本文的第二部分會對監控與調整緩衝池大小作詳細解讀。

應該設置告警的指標：

查詢運行時間：管理關鍵數據庫的延遲相當重要。若是生產環境中數據庫的平均查詢運行時間開始降低，應該尋找數據庫實例的資源限制，行鎖或表鎖間可能的爭奪，以及客戶端查詢模式的變化狀況。
查詢錯誤：查詢錯誤的猛增可能暗示着客戶端應用或數據庫自己的問題。你可使用 sys 模式快速查找可能致使問題的查詢。例如，列舉出返回錯誤數最多的10條標準化語句：
```
SELECT * FROM sys.statements_with_errors_or_warnings 
   ORDER BY errors DESC LIMIT 10;
```
Slow_queries：如何定義慢查詢（並由此設置 long_query_time 參數）取決於你的用戶案例。可是，不管你如何定義「慢」，你都會想知道慢查詢的數量是否超出了基準水平。爲了找出真正執行緩慢的查詢，你能夠詢問 sys 模式，或深刻了解 MySQL 提供的慢查詢日誌（該功能默認是禁用的）。有關啓用並讀取慢查詢日誌的更多信心，請參考 MySQL 文檔。

敬請期待本文第二部分，主要介紹 MySQL 鏈接與緩衝池。

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

本文轉自 OneAPM 官方博客