查詢吞吐量
查詢執行性能
連接配接情況
緩沖池使用情況
mysql 使用者可以接觸到數百個資料庫名額，是以，在本文中，筆者将專注于能幫助我們實時了解資料庫健康與性能的關鍵名額。
不同版本與技術的相容性
本系列文章讨論的一些監控政策隻适用于 mysql 5.6與5.7版本。這些版本間的差異将在後文中提及。
本文列出的大多數名額與監控政策同樣适用于與 mysql 相容的技術，諸如 mariadb 與 percona 伺服器，不過帶有一些明顯的差别。例如，mysql workbench(工作台)中的一些特性（在本系列第二篇中有詳細介紹）就與當下的一些 mariadb 版本不相容。
名稱
描述
名額類型 可用性
questions
已執行語句（由用戶端發出）計數
work：吞吐量 伺服器狀态變量
com_select
select 語句
writes
插入，更新或删除
work：吞吐量 根據伺服器狀态變量計算得到
在監控任何系統時，你最關心的應該是確定系統能夠高效地完成工作。資料庫的工作是運作查詢，是以在本例中，你的首要任務是確定 mysql 能夠如期執行查詢。
通過以下指令，查詢諸如 <code>questions</code> 或 <code>com_select</code> 伺服器狀态變量的值：
你也可以監控讀、寫指令的分解情況，進而更好地了解資料庫的工作負載、找到可能的瓶頸。通常，讀取查詢會由 <code>com_select</code> 名額抓取，而寫入查詢則可能增加三個狀态變量中某一個的值，這取決于具體的指令：
應該設定告警的名額：questions
目前的查詢速率通常會有起伏，是以，如果基于固定的臨界值，查詢速率常常不是一個可操作的名額。但是，對于查詢數量的突變設定告警非常重要——尤其是查詢量的驟降，可能暗示着某個嚴重的問題。
查詢性能
查詢運作時間
每種模式下的平均運作時間
work：性能 性能模式查詢
查詢錯誤
出現錯誤的 sql 語句數量
work：錯誤 性能模式查詢
slow_queries
超過可配置的<code>long_query_time</code> 限制的查詢數量
work：性能 伺服器狀态變量
性能模式語句摘要
性能模式的 <code>events_statements_summary_by_digest</code> 表格中儲存着許多關鍵名額，抓取了與每條标準化語句有關的延遲、錯誤和查詢量資訊。從該表截取的一行樣例顯示，某條語句被執行了兩次，平均執行用時為 325 毫秒（所有計時器的測量值都以微微秒為機關）：
想要按模式抽取出以微秒為機關的平均運作時間，你可以這樣查詢性能模式：
相似地，按模式計算出現錯誤的語句總數，可以這麼做：
sys 模式
或者檢視哪些标準化語句出現了錯誤：
慢查詢
除了性能模式與 sys 模式中豐富的性能資料，mysql 還提供了一個 <code>slow_queries</code> 計數器，每當查詢的執行時間超過 <code>long_query_time</code> 參數指定的值之後，該計數器就會增加。預設情況下，該臨界值設定為10秒。
<code>long_query_time</code> 參數的值可通過一條指令進行調整。例如，将慢查詢臨界值設定為5秒：
（請注意，你可能要關閉會話，再重新連接配接至資料庫，這些更改才能在會話層生效。）
調查查詢性能問題
如果你的查詢運作得比預期要慢，很可能是某條最近修改的查詢在搗鬼。如果沒有發現特别緩慢的查詢，接下來就該評估系統級名額，尋找核心資源（cpu，磁盤 i/o，記憶體以及網絡）的限制。cpu 飽和與 i/o 瓶頸是常見的問題根源。你可能還想檢查 <code>innodb_row_lock_waits</code> 名額，該名額記錄着 innodb 存儲引擎不得不停下來獲得某行的鎖定的次數。從 mysql 5.5 版本起，innodb 就是預設的存儲引擎，mysql 對 innodb 表使用行級鎖定。
應該設定告警的名額：
查詢運作時間：管理關鍵資料庫的延遲至關重要。如果生産環境中資料庫的平均查詢運作時間開始下降，應該尋找資料庫執行個體的資源限制，行鎖或表鎖間可能的争奪，以及用戶端查詢模式的變化情況。
查詢錯誤：查詢錯誤的猛增可能暗示着用戶端應用或資料庫本身的問題。你可以使用 sys 模式快速查找可能導緻問題的查詢。例如，列舉出傳回錯誤數最多的10條标準化語句：
敬請期待本文第二部分，主要介紹 mysql 連接配接與緩沖池。