GaussDB(DWS)历史TopSQL记录不全问题分析

为了避免TopsQL功能的启用对数据库性能产生很大的影响，实时TopSQL（statistics后缀的）和历史TopSQL（history后缀的）是存放在内存中的临时表，分别是在语句运行时更新和运行结束时从statistics转存到history，二者都为hash临时表，想要长时间保存就需要进行转存操作，将history表中信息转存到info表中，默认为3分钟自动转存。

在8.0及以下版本的高负载业务集群中经常会出现历史TopSQL记录不全的情况，对定位性能问题、日常调优、资源配置参考等带来很大不便。8.0版本的产品文档中对TopSQL的记录存储限制做了以下说明：

       由此可知，存储实时TopSQL记录的hash临时表容量是有上限的，当达到上限，则不再记录新的语句信息，导致历史TopSQL中出现部分语句记录丢失的情况。具体过程以下图为例说明：

       涉及TopSQL记录的有2个实时视图和1个历史表，数据写入有两个过程，分别为实时视图写入历史视图，然后每隔3分钟再永久写入历史表。因此，记录写入丢失的情况只会出现在实时写入阶段。假设在T0时刻，历史视图刚刚完成一次转储，其hash内存表中的信息已全部清空，等待新的记录写入。当业务并发较高时，在T1时刻就写满了历史视图，此时距离下一次转储还不到3分钟。由于历史视图hash内存表容量已达上限，导致T1-T2时段的SQL语句无法写入到历史视图，该部分记录则会丢失。

另外由于8.0版本TopSQL使用hash内存表的结构，语句监控模块在CN和DN上会同时向实时hash中插入、更新、删除正在运行的SQL信息，当业务线程并发度增大时，排他锁冲突概率也会增大。对分布式系统而言，每个CN/DN都有相同的锁冲突概率，集群规模越大，锁冲突概率越大。在这种情况下，会导致语句记录不全，当历史TopSQL数据量很大时，查询效率往往极低。

8.1.2版本对TopSQL架构进行了重构，使用无锁队列代替了hash内存表。新的架构解决了锁冲突和历史TopSQL记录不全的问题，同时带来了以下重要更新：

• 支持子语句监视，将存储过程、匿名块、函数体中下发到DN上执行的语句，作为需要监视的子语句，在GUC参数enable_track_record_subsql开启的情况下，会将子语句也记录到INFO表，其queryid会和主语句一致；
• 支持DDL、DCL、TCL语句；
• CURSOR语句增强，不仅仅记录session中的第一个FETCH语句，FETCH作为主语句的情况下，都会被记录，能显示原语句和执行计划；FRTCH作为子语句的情况下，只有下发到DN上执行，才会被记录，也能显示原语句和执行计划；
• INFO表分区表改造和老化机制修改，按时间做分区，能提升查询效率，按分区老化，能回收空间。