DBAIOps 关键 SQL 监控功能

D-SMART 社区版发布一个重要的升级版本，届时所有的社区版用户都可以使用 PATCH 工具直接升级而不用重新安装。这个版本中的有一个十分有趣的功能，就是关键 SQL 监控。实际上在 2.1.6 版本中 D-SMART 已经具备了关键 SQL 跟踪的能力，可以及时发现关键 SQL 执行中发生的问题。在 V2.2 中的关键 SQL 跟踪会支持社区版支持的所有数据库对象，包括 Oracle、MySQL、达梦、PG 系列（包括高斯，金仓等）。

关键 SQL，顾名思义就是在系统中比较关键的 SQL 语句，一旦这些 SQL 出现问题，就会对系统的性能产生很大的影响，对核心业务产生影响。

最近我也遇到过几个客户遇到关键 SQL 性能问题导致核心业务被迫暂时下线的严重故障。他们问我能不能实时监控 SQL 语句的执行计划，当 SQL 执行计划出问题的时候能够告警。我当时的回答是，对于业务负载较大的大型系统中，直接监控所有的执行计划既不必要，成本也过高，弄不好这个监控反而会引发一些高并发执行的 SQL 的性能问题。

后来我就考虑这个业务的需求是什么，用户希望当系统中某条 SQL 发生异常时能够及时感知，及时告警，被及时识别出来。于是就有了关键 SQL 告警这个功能。这个功能在 V2.1.6 版本中就已经上线了。

仅仅有告警还不能满足一些用户的需求，对于一些十分核心的系统，很多用户希望构建关键 SQL 监控的能力。能够在监控大屏上很直观的看到这些 SQL 的执行情况。于是就有了关键 SQL 监控这个功能。

关键 SQL 监控不仅仅是一个监控，而是一个对于关键 SQL 进行监控、预警、分析的集成化入口。因此我们同时在监控界面上集成了关键 SQL 告警的数据。在这里我们不需要通过告警中心，就可以直接进行关键 SQL 告警分析。

当系统中出现了关键 SQL 告警的时候，在某个维度会显示告警数量的红色警示。此时我们就可以进行下钻分析了。

点击进去可以查看详情，点击 SQL 详情分析可以对这条 SQL 进行分析诊断。这里调用的诊断工具与在告警中心的“运维经验告警”模块中点击诊断效果是完全一致的。

通过这个诊断工具，我们发现了一张大表上缺乏索引，进行了全表扫描的问题。

关键 SQL 监控与告警，对于证券、银行、运营商等的一些大并发量的关键系统的保驾护航还是挺有意义的。有很多 SQL 很可能平时都不会出现在数据库的 TOP SQL 中，但是这些 SQL 是十分关键的。一旦这些 SQL 出现一些异常，会引发业务的严重问题。一条平时 10 个逻辑读的 SQL，可能每秒执行数量就高达数百次，如果走错了执行计划，逻辑读变成 10 万一次了，那么很可能服务器的 CPU 就爆掉了，或者热块冲突就十分严重了。这时候如果我们能够提前感知，提前处置，或者故障发现时能够快速定位，快速找到解决方案，是很有价值的。

哪怕 SQL 没有走错执行计划，由于做了某些维护操作，表的数据量发生了较大的变化，或者出现了很多碎片，也可能引发关键 SQL 的性能问题。集群延时增加，也会导致关键 SQL 执行变慢。而 SQL 执行变慢后，又会引发某条 SQL 的并发执行量越来越大，从而进一步恶化数据库的整体性能，最终引发严重故障。

根据用户的需求，我们会不断的优化迭代这个功能，我想今后一些核心系统迁移到信创数据库上，这个功能就更有用武之地了。