慢SQL监控最早是MySQL的特色功能，在此之前，Oracle的AWR报告中提供TOP SQL分析。通过优化TOP SQL来解决数据库的性能问题，消除大型隐患是做Oracle优化时经常用的手段。早期的MySQL比较简单，一旦系统中出现大量的慢SQL，整个单进程的MySQL服务就会出严重的性能问题，因此慢SQL监控一直是MySQL中十分重要的工具。
目前我们的国产数据库受MySQL思想的影响很深，因此很多国产数据库也提供慢SQL监控的功能。只不过很多用户用过之后，感觉这个功能在大多数情况下有些鸡肋。打开监控后系统开销很大，而且监控发现的SQL往往并不关键。因为发现的慢SQL往往本身就是比较复杂的查询语句，执行时间就比较长。大部分SQL优化不优化关系并不大。
这和我二十年前做数据库优化一样，优化了大量的TOP SQL，从数据库的各项指标上提升很大，CPU使用率也降低了不少，平均事务响应时间也提升很大，但是系统的使用者的感受并不明显。
实际上对于用户来说，需要的关于SQL的可观测性能力与我们的数据库厂商提供的能力并不一致。用户对于SQL监控可观测性接口的需求要复杂得多。不同的系统对于SQL监控方面的需求也是不同的。
本月20号发布的D-SMART社区版V2.2中，我们会发布一个十分有趣的功能-就是关键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而把CPU、内存等资源耗尽了，那么系统也就会出大问题了。
实际上用户所需要的对SQL执行计划的监控功能，如果从监控软件的角度来做十分不合适，因此我们只能通过一些曲线的手段来解决客户的关键SQL监控预警的问题。如果这些事情由数据库内核来做，那么会简单得多，也高效得多。比如关键SQL的发现，基于AI4DB的一些算法，可以更为精准的发现真正的关键SQL，因为在数据库的核心引擎中，具有更多的有效时间，可以做更为精准的分析与判断。
一些执行十分频繁的SQL语句，其执行计划变坏，执行成本大幅提升，如果在SQL引擎中能够输出一些标签数据，那么监控工具也就能够更方便的进行监控了。这对于数据库核心来说，只是举手之劳，而如果要让外挂的数据库监控工具来说，就十分困难了。
关键SQL的自动标注、执行计划变坏预警、SQL问题风险提示，以目前的软硬件环境来说，这些功能完全可以在数据库核心里实现，或者由SQL引擎内核输出一些关键数据，供运维工具使用。而一些内核中外挂的工具也可以利用数据库的AI4DB能力，利用系统较为空闲的窗口进行自动分析，直接输出一些分析报告。
数据库信创替代工作开展后，运维经验的积累是个长期的过程，因此在短期内，SQL优化将是数据库信创替代的关键业务。因此也希望我们的国产数据库厂商打破思维的固有限制，不要被MySQL慢SQL监控这种思路固化，在内核中提升SQL监控跟踪能力的数据输出，更好的为数据库信创替代服务。
