如何快速统计经常进行delete的表，释放其存储空间

目标：
解决经常进行delete操作的表，但是数据占用的存储没有释放出来的问题。
思路和问题：    
1，如何获取频繁进行delete操作的表名；
2，经常进行delete操作的这些表，当前实际存储有多大，是否真的需要重建释放空间？

解决问题1：
1，可以通过gbase.audit_log审计日志获取库内执行过的所有sql，但是gbase 8a是分布式数据库，每个gcluster节点只记录该管理节下发的sql，为了便于查询建议做一套审计日志汇总的表，如何汇总审计日志这里不进行详细描述。
以我的审计日志为例，表结构如下：

一共需要使用该表的3个字段如下：
start_time    任务的开始时间
table_list    任务执行涉及到的表
sql_command    任务的分类
参考sql如下：

该sql用于通过获取，2025年4月1日以来，进行全表delete次数超过10次的表名，为了展示方便这里对delete操作多的表进行了倒序排列，实际只需要获取表名即可。
另外这里对table_list字段格式做一下说明
该字段格式为` WRITE: `<db>`.`<tb>`;READ: `<db>`.`<tb>`; OTHER: `<db>`.`<tb>`;
我们只需要获取` WRITE: `<db>`.`<tb>`;部分中的表名即可，也就是进行delete的表名，READ和OTHER部分的表名这里用不到，所以这里对table_list截取并格式化。
还可以对table_list字段再次通过’.’为分隔符进行分割，单独获取库名和表名两个字段用于后续表大小查询。
以上就是获取频繁进行delete操作的表名获取方式。

解决问题2：
如何获取这些表当前实际大小，该问题可以直接查询gbase的系统表：
Information_schema.custer_table_segments
具体sql如下：

这里需要注意的问题是，该表是一张内存表，实际不存储数据，当查询该表时，会去扫表数据盘来获取数据，所以一定要注意，查询时要对库名和表名这两个字段同时做等值查询，不可模糊查询。
建议通过脚本的方式，获取表名并生成列表，通过脚本循环获取每张表的大小。

总结：
通过上述描述，就可以获取4月以来，进行全表进行delete操作超过10次的库名、表名、和实际表大小，这三个字段。然后就可以按照转储，新建表的方式释放存储。