数据库监控方案
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 中，以便我们后面做进一步分析使用。