背景
在此前的「UAVStack的慢SQL数据库监控功能及其实现」一文中，我们提到，数据库连接池监控能够让运维人员随时了解数据库连接池的状态，有效防止系统出现连接池活动连接数占满无法连接数据库的情况；而慢SQL监控功能则可以动态展示一个系统的SQL情况，帮助优化SQL语句，让系统更稳定。

今天我们通过三个案例继续介绍数据库监控功能在实际场景中的应用，帮助大家更好地了解这一利器。

案例一
WechatIMG26.jpeg

上图是一个服务新功能上线的案例。

当时UAV收到了数据库慢SQL告警，登录系统进行问题诊断后，我们通过数据库监控发现了大量缓慢调用。

一条相对简单的SQL，执行了603次，平均执行时间达到1328.97ms，最大执行时间为1815ms。

原因在于新功能上线后，相关运维人员未及时增加索引。

WechatIMG27.jpeg

点击图1中某一行可以查看详情（如图2所示）。本页列表包括了每一条SQL的开始执行时间、执行时长、入参、执行结果，可以看到每条SQL的执行时长均在1200ms+。

WechatIMG28.jpeg

点击图2中某一行的调用链关联，可以跳转至本次SQL调用对应应用/服务的一条端到端完整的调用链路，JDBC操作对应的调用环节高亮显示，如图3所示。

案例二
WechatIMG29.jpeg

上图为某外购催收系统的优化案例。

在系统未优化前，9:30-10:30单个服务节点的QPM为6000+，而给后端数据库带来的QPM是13–14+万。通过数据库QPM与服务节点QPM的比值可知，每个服务请求对数据库带来的SQL操作数为20+。

系统优化后，服务节点QPM不变，而数据库QPM下降到2–4万，数据库QPM与服务节点QPM的比值也下降到5左右。从监控层面上来看，系统优化效果还是比较明显的。

本文转载自宜信技术学院网站。

原文链接：http://college.creditease.cn/detail/268

宜信开源 | 案例：UAVStack 的慢 SQL 数据库监控实战（上）