背景
在此前的「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
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论