數據庫監控方案
1. 查詢吞吐量
| 名稱 |
描述 |
指標類型 |
可用性 |
| Questions |
已執行語句（由客戶端發出）計數 |
Work：吞吐量 |
服務器狀態變量 |
| Com_select |
SELECT 語句 |
Work：吞吐量 |
服務器狀態變量 |
| Writes |
插入，更新或刪除 |
Work：吞吐量 |
根據服務器狀態變量計算得到 |
1) Questions：
SHOW GLOBAL STATUS LIKE "Questions";
2) Writes：
Writes = Com_insert + Com_update + Com_delete
提示：
當前的查詢速率通常會有起伏，因此，如果基於固定的臨界值，查詢速率常常不是一個可操作的指標。但是，對於查詢數量的突變設置告警非常重要——尤其是查詢量的驟降，可能暗示着某個嚴重的問題。
2. 查詢執行性能
| 名稱 |
描述 |
指標類型 |
可用性 |
| 查詢運行時間 |
每種模式下的平均運行時間 |
Work：性能 |
性能模式查詢 |
| 查詢錯誤 |
出現錯誤的 SQL 語句數量 |
Work：錯誤 |
性能模式查詢 |
| Slow_queries |
超過可配置的long_query_time 限制的查詢數量 |
Work：性能 |
服務器狀態變量 |
1) 查詢錯誤，計算出現錯誤的語句總數：
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;
2) 慢查詢
查詢設置的臨界值: SHOW VARIABLES LIKE 'long_query_time';
將慢查詢臨界值設置為 5 秒: SET GLOBAL long_query_time = 5;
打開慢查詢日志：set global slow_query_log='ON'
調查查詢性能問題
如果你的查詢運行得比預期要慢，很可能是某條最近修改的查詢在搗鬼。如果沒有發現特別緩慢的查詢，接下來就該評估系統級指標，尋找核心資源（CPU，磁盤 I/O，內存以及網絡）的限制。CPU 飽和與 I/O 瓶頸是常見的問題根源。你可能還想檢查 Innodb_row_lock_waits 指標，該指標記錄着 InnoDB 存儲引擎不得不停下來獲得某行的鎖定的次數。從 MySQL 5.5 版本起，InnoDB 就是默認的存儲引擎，MySQL 對 InnoDB 表使用行級鎖定。
應該設置告警的指標：
- 查詢運行時間：管理關鍵數據庫的延遲至關重要。如果生產環境中數據庫的平均查詢運行時間開始下降，應該尋找數據庫實例的資源限制，行鎖或表鎖間可能的爭奪，以及客戶端查詢模式的變化情況。
- 查詢錯誤：查詢錯誤的猛增可能暗示着客戶端應用或數據庫本身的問題。你可以使用 sys 模式快速查找可能導致問題的查詢。例如，列舉出返回錯誤數最多的 10 條標准化語句：
SELECT * FROM sys.statements_with_errors_or_warnings
ORDER BY errors DESC LIMIT 10;
3. 連接情況
| 名稱 |
描述 |
指標類型 |
可用性 |
| Threads_connected |
當前開放的連接 |
資源: 利用率 |
服務器狀態變量 |
| Threads_running |
當前運行的連接 |
資源: 利用率 |
服務器狀態變量 |
| Connection_errors_internal |
由服務器錯誤導致的失敗連接數 |
資源: 錯誤 |
服務器狀態變量 |
| Aborted_connects |
嘗試與服務器進行連接結果失敗的次數 |
資源: 錯誤 |
服務器狀態變量 |
| Connection_errors_max_connections |
由 max_connections 限制導致的失敗連接數 |
資源: 錯誤 |
服務器狀態變量 |
1) 最大連接數：SHOW VARIABLES LIKE 'max_connections';
2) 監控連接使用率
MySQL 提供了 Threads_connected 指標以記錄連接的線程數——每個連接對應一個線程。通過監控該指標與先前設置的連接限制，你可以確保服務器擁有足夠的容量處理新的連接。MySQL 還提供了Threads_running 指標，幫助你分隔在任意時間正在積極處理查詢的線程與那些雖然可用但是閑置的連接。
如果服務器真的達到 max_connections 限制，它就會開始拒絕新的連接。在這種情況下，Connection_errors_max_connections 指標就會開始增加，同時，追蹤所有失敗連接嘗試的Aborted_connects 指標也會開始增加。
MySQL 提供了許多有關連接錯誤的指標，幫助你調查連接問題。Connection_errors_internal 是個很值得關注的指標，因為該指標只會在錯誤源自服務器本身時增加。內部錯誤可能反映了內存不足狀況，或者服務器無法開啟新的線程。
3) 應該設置告警的指標
- Threads_connected：當所有可用連接都被占用時，如果一個客戶端試圖連接至 MySQL，后者會返回 “Too many connections(連接數過多)” 錯誤，同時將Connection_errors_max_connections 的值增加。為了防止出現此類情況，你應該監控可用連接的數量，並確保其值保持在 max_connections 限制以內。
- Aborted_connects：如果該計數器在不斷增長，意味着用戶嘗試連接到數據庫的努力全都失敗了。此時，應該借助 Connection_errors_max_connections 與 Connection_errors_internal 之類細粒度高的指標調查該問題的根源。
4. 緩沖池使用情況
| 名稱 |
描述 |
指標類型 |
可用性 |
| Innodb_buffer_pool_pages_total |
緩沖池中的總頁數 |
資源: 利用率 |
服務器狀態變量 |
| 緩沖池使用率 |
緩沖池中已使用頁數所占的比率 |
資源: 利用率 |
根據服務器狀態變量計算得到 |
| Innodb_buffer_pool_read_requests |
向緩沖池發送的請求 |
資源: 利用率 |
服務器狀態變量 |
| Innodb_buffer_pool_reads |
緩沖池無法滿足的請求 |
資源: 飽和度 |
服務器狀態變量 |
1) 檢查緩沖池的大小
緩沖池大小調整操作是分塊進行的，緩沖池的大小必須為塊的大小乘以實例的數目再乘以某個倍數。
innodb_buffer_pool_size = N * innodb_buffer_pool_chunk_size
* innodb_buffer_pool_instances
查詢塊的大小（單位字節）：
SHOW GLOBAL VARIABLES LIKE "innodb_buffer_pool_chunk_size";
2) 關鍵的 InnoDB 緩沖池指標
指標算法：
(Innodb_buffer_pool_pages_total - Innodb_buffer_pool_pages_free) / Innodb_buffer_pool_pages_total
提示：根據利用率是決定是否增加緩沖池的大小
如果你的數據庫從磁盤進行大量讀取，而緩沖池還有許多閑置空間，這可能是因為緩存最近才清理過，還處於熱身階段。如果你的緩沖池並未填滿，但能有效處理讀取請求，則說明你的數據工作集相當適應目前的內存配置。
然而，較高的緩沖池利用率並不一定意味着壞消息，因為舊數據或不常使用的數據會根據 LRU 算法 自動從緩存中清理出去。但是，如果緩沖池無法有效滿足你的讀取工作量，這可能說明擴大緩存的時機已至。
3) 將緩沖池指標轉化為字節
大多數緩沖池指標都以內存頁面為單位進行記錄，但是這些指標也可以轉化為字節，從而使其更容易與緩沖池的實際大小相關聯。例如，你可以使用追蹤緩沖池中內存頁面總數的服務器狀態變量找出緩沖池的總大小（以字節為單位）：
Innodb_buffer_pool_pages_total * innodb_page_size
InnoDB 頁面大小是可調整的，但是默認設置為 16 KiB，或 16,384 字節。你可以使用 SHOW VARIABLES 查詢了解其當前值：
SHOW VARIABLES LIKE "innodb_page_size";
參考地址：https://www.cnblogs.com/zengkefu/p/5658252.html
5. 數據庫鎖的機制
5.1系統鎖定急用情況下查詢
1) MySQL 實現的表級鎖定的爭用狀態變量：mysql>show status like 'table%';
這里有兩個狀態變量記錄 MySQL 內部表級鎖定的情況，兩個變量說明如下：
● Table_locks_immediate：產生表級鎖定的次數；
● Table_locks_waited：出現表級鎖定爭用而發生等待的次數；
兩個狀態值都是從系統啟動后開始記錄，沒出現一次對應的事件則數量加 1。如果這里的
Table_locks_waited 狀態值比較高，那么說明系統中表級鎖定爭用現象比較嚴重，就需要進一步分析為什么會有較多的鎖定資源爭用了。
2) 對於 Innodb 所使用的行級鎖定，系統中是通過另外一組更為詳細的狀態變量來記錄的，如下：mysql> show status like 'innodb_row_lock%';
Innodb 的行級鎖定狀態變量不僅記錄了鎖定等待次數，還記錄了鎖定總時長，每次平均時長，以及
最大時長，此外還有一個非累積狀態量顯示了當前正在等待鎖定的等待數量。對各個狀態量的說明如
下：
● Innodb_row_lock_current_waits：當前正在等待鎖定的數量；
● Innodb_row_lock_time：從系統啟動到現在鎖定總時間長度；
● Innodb_row_lock_time_avg：每次等待所花平均時間；
● Innodb_row_lock_time_max：從系統啟動到現在等待最常的一次所花的時間；
● Innodb_row_lock_waits：系統啟動后到現在總共等待的次數；
對於這 5 個狀態變量，比較重要的主要是 Innodb_row_lock_time_avg（等待平均時長），
Innodb_row_lock_waits（等待總次數）以及 Innodb_row_lock_time（等待總時長）這三項。尤其是當等待次數很高，而且每次等待時長也不小的時候，我們就需要分析系統中為什么會有如此多的等待，然后根據分析結果着手指定優化計划。
此外，Innodb 出了提供這五個系統狀態變量之外，還提供的其他更為豐富的即時狀態信息供我們分析使用。可以通過如下方法查看：
1. 通過創建 Innodb Monitor 表來打開 Innodb 的 monitor 功能：
mysql> create table innodb_monitor(a int) engine=innodb;
Query OK, 0 rows affected (0.07 sec)
2. 然后通過使用“SHOW INNODB STATUS”查看細節信息（由於輸出內容太多就不在此 記錄了）；
可能會有讀者朋友問為什么要先創建一個叫 innodb_monitor 的表呢？因為創建該表實際上就是告訴Innodb 我們開始要監控他的細節狀態了，然后 Innodb 就會將比較詳細的事務以及鎖定信息記錄進入MySQL 的 error log 中，以便我們后面做進一步分析使用。