背景
在此前的「UAVStack的慢SQL数据库监控功能及其实现」一文中，我们提到，数据库连接池监控能够让运维人员随时了解数据库连接池的状态，有效防止系统出现连接池活动连接数占满无法连接数据库的情况；而慢SQL监控功能则可以动态展示一个系统的SQL情况，帮助优化SQL语句，让系统更稳定。
今天我们通过三个案例继续介绍数据库监控功能在实际场景中的应用，帮助大家更好地了解这一利器。
案例一
上图是一个服务新功能上线的案例。
当时UAV收到了数据库慢SQL告警，登录系统进行问题诊断后，我们通过数据库监控发现了大量缓慢调用。
一条相对简单的SQL，执行了603次，平均执行时间达到1328.97ms，最大执行时间为1815ms。
原因在于新功能上线后，相关运维人员未及时增加索引。
点击图1中某一行可以查看详情（如图2所示）。本页列表包括了每一条SQL的开始执行时间、执行时长、入参、执行结果，可以看到每条SQL的执行时长均在1200ms+。
点击图2中某一行的调用链关联，可以跳转至本次SQL调用对应应用/服务的一条端到端完整的调用链路，JDBC操作对应的调用环节高亮显示，如图3所示。
案例二
上图为某外购催收系统的优化案例。
在系统未优化前，9:30-10:30单个服务节点的QPM为6000+，而给后端数据库带来的QPM是13–14+万。通过数据库QPM与服务节点QPM的比值可知，每个服务请求对数据库带来的SQL操作数为20+。
系统优化后，服务节点QPM不变，而数据库QPM下降到2–4万，数据库QPM与服务节点QPM的比值也下降到5左右。从监控层面上来看，系统优化效果还是比较明显的。
案例三
上图还是关于该外购催收系统的案例。
催收系统在查询催收历史时，统计记录数的count(*)语句，因为执行计划异常，执行效率低，占用了大量资源，导致数据库服务器CPU资源耗尽，进而催收系统不可用。
通过图5中可以看到，故障期间的慢SQL数目明显变大，慢SQL具体为count(*)语句。
通过图6可以发现，故障期间的连接池资源被耗尽，活动连接数达到峰值，而空闲连接数为0；SQL分类统计图表也显示故障期间查询错误SQL数量明显变大。
查看故障期间的慢SQL列表，3种执行时间长的SQL全是count(*)语句。
查看故障期间的慢SQL详情及与调用链关联，均显示了count(*)语句执行时间长以及执行错误。
关于数据库监控的应用实例就介绍到这里。欢迎大家持续关注UAVStack，与我们一起解锁更多智能运维新能力。
官方网站：https://uavorg.github.io/main/ 开源地址：https://github.com/uavorg
作者：谢知求
原文首发 UAVStack智能运维
