資料庫監控方案
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 中，以便我們後面做進一步分析使用。