【TiDB 使用环境】测试
【TiDB 版本】8.5.0
【操作系统】linux
【部署方式】机器部署（16G 32核 机械硬盘）
【集群数据量】
【集群节点数】单节点 unistore
【问题复现路径】不断重复RUNCATE TABLE删除表数据，导入数据，查询磁盘剩余空间
【遇到的问题】内存占用不断升高，data/kv中的sst文件不断增多，等待长时间完全没有被gc回收；依据最新的日志来分析判断，gc好像有执行（图三）？只是表空间没有被回收的样子（图四是sst文件，28号17点到29号10点，数据依然存在）
没太明白你的意思
一直插入跟查询，数据肯定越来越多，这不是正常的吗？
删除操作呢？
不做删除处理，肯定越来越多咯
GC 是针对做删除标记的资源进行有序的回收
不好意思，描述不正确，是RUNCATE TABLE、导入表数据、查询磁盘剩余空间
不好意思，描述不正确，执行RUNCATE TABLE进行了删除操作
描述遗漏，有RUNCATE TABLE删除了数据
truncate 立马释放了吧。如果一直有数据删除。那gc肯定也在一直运行
按照我图三的日志，应该是执行了gc，但是sst文件没有被回收
gc只是将打标为删除的数据进行清理，避免sql扫描再扫到已删除的数据，空间像释放得等compact，或者手动compact
unistore好像没有手动触发compact的方法
手动compact一下
unistore我没用过，你看下支持
ADMIN COMPACT TABLE <table_name>;
语法吗？
你要去监控看看最新GC位点到了什么时候，是否覆盖了你删除数据的时间，如果覆盖了，那就应该删除
貌似语法是ALTER TABLE <table_name> COMPACT;，不过可惜我并没有有效作用
目前正要学习如何使用监控这个功能，您是否有什么指导方向