慢SQL监控是MySQL最早的特性。在此之前，Oracle的AWR报告提供了TOPSQL分析。通过优化TOPSQL解决数据库性能问题，消除较大隐患，是Oracle优化常用的方法。早期的MySQL比较简单。一旦系统出现大量慢SQL，整个单进程MySQL服务就会出现严重的性能问题。因此，慢SQL监控一直是MySQL中非常重要的工具。目前我们国内的数据库深受MySQL思想的影响，所以国内很多数据库也提供了慢SQL监控的功能。只是很多用户在使用之后，觉得这个功能在大多数情况下有点鸡肋。开启监控后，系统开销很大，而且监控发现的SQL往往并不关键。因为找到的慢SQL往往是比较复杂的查询语句，执行时间比较长。大多数SQL优化与优化没有太大关系。这和我20年前做的数据库优化是一样的。我对大量TOPSQL进行了优化，大大提升了数据库的各项指标，降低了很多CPU占用率，大大提高了平均事务响应时间。但是，系统用户的感受并不明显。其实对于用户来说，需要的SQL可观测能力和我们数据库厂商提供的能力是不一致的。SQL监控可观察性接口的用户需求要复杂得多。不同的系统对SQL监控有不同的要求。在本月20日发布的D-SMART社区版V2.2中，我们将发布一个非常有意思的功能——关键SQL监控。V2.2关键SQL跟踪将支持社区版支持的所有数据库对象，包括Oracle、MySQL、大梦、PG系列（包括汉高、高斯、金仓、Massive、优轩等）。顾名思义，“关键SQL”是系统中比较关键的SQL语句。一旦这些SQL出现问题，将会对系统的性能和核心业务产生很大的影响。最近，我也遇到了严重的故障，几个客户遇到严重的SQL性能问题，迫使核心业务暂时下线。前段时间有个用户问我，能不能帮他们实时监控SQL语句的执行计划，当SQL执行计划出现问题时报警。我当时的回答是，对于业务负载很重的大型系统，直接监控所有的执行计划是没有必要的，成本也很高。如果这个监控没有做好，就会导致一些高并发执行的SQL出现性能问题。后来考虑到这个业务的需求。用户希望当系统中某条SQL出现异常时，能及时察觉，及时报警，及时识别。于是就有了按键SQL告警的功能。该功能已在V2.1.6版本上线。仅靠告警不能满足部分用户的需求。对于一些非常核心的系统，很多用户希望构建关键的SQL监控能力。在监控大屏上可以直观的看到这些SQL的执行情况。于是就有了关键SQL监控的功能。关键SQL分为几类。第一类是关键业务和关键数据相关的SQL语句。这些SQL语句一旦执行缓慢，就会导致核心业务出现问题；数据库中的数据量可能变化很大，同时索引数量多，容易出现执行计划错误的SQL语句。一旦这些语句出现执行计划错误，执行成本可能会增加数百倍甚至数万倍。一旦CPU、内存等资源因为这些SQL而耗尽，系统就会出现大问题。实际上，用户需要的SQL执行计划的监控功能从监控软件的角度来说是非常不合适的，所以我们只能通过一些曲线的方式来解决客户关键的SQL监控预警问题。如果这些事情都由数据库内核来做，会简单很多，效率也会高很多。比如关键SQL的发现，基于AI4DB的一些算法，可以更准确的发现真正的关键SQL，因为数据库的核心引擎有更多的有效时间，可以做更准确的分析判断。对于一些频繁执行的SQL语句，执行计划变坏，执行成本大大增加。如果在SQL引擎中可以输出一些标签数据，那么监控工具就可以更方便的进行监控。对于数据库核心来说，这只是小菜一碟，但是对于插件化的数据库监控工具来说，难度就很大了。关键SQL自动标注，执行计划劣化预警，SQL问题风险预警。基于目前的软硬件环境，这些功能完全可以在数据库内核中实现，或者一些关键数据可以由SQL引擎内核输出，供运维工具使用。使用。而内核中的一些插件工具也可以利用数据库的AI4DB能力，利用系统相对空闲的窗口进行自动分析，直接输出一些分析报告。数据库更换工作进行后，运维经验的积累是一个长期的过程。因此，短期内，SQL优化将是数据库换代的重点业务。所以，我们也希望我们国内的数据库厂商能够突破先天的思维局限，不被MySQL慢SQL监控的思想固化，在内核中提高SQL监控和跟踪能力的数据输出，所以以更好地服务数据库新创作为备选方案。
