【详述】问题详细描述
【背景】做过哪些操作？
Truncate partition后，发现trash目录的磁盘空间占用量增加，但是在没达到配置的trash保存时间前，一直未释放磁盘。这个设计感觉不合理。因为文档中，对truncate的描述就是：“ 该操作删除的数据 不可恢复 ”，既然是这样，就不应该还让数据在trash目录继续保存。
参照文档：https://docs.starrocks.com/zh-cn/2.2/sql-reference/sql-statements/data-definition/TRUNCATE%20TABLE
【业务影响】
【StarRocks版本】2.2.2
可以手动先把trash目录里面的数据手动删除掉
但是这样并不合理，本身就是不可恢复的数据，还要被放到trash中。。。
也没有提供类似drop force的机制
drop table table_name force;可以试下这个
这个我知道，但是现在的场景是只想强制清除单个分区的数据。
现在如果我想要实现，需要用drop paritition force + add partition两步操作来实现一个强制清除单分区的功能。
truncate是直接删除，没有放到trash里面。请问下您是基于什么信息下的这个判断呢？
truncate是直接删除，没有放到trash里面。请问下您是基于什么信息下的这个判断呢？
这边有个脚本用truncate partition + load，去实现数据的重新导入。昨天大量执行了这个操作。在经历过这样的过程后，告警了磁盘使用量大于90%，然后就发现trash占用量特别大。只可能是truncate导致trash目录占用量巨大，不会是load吧？
您可以先手动删除下trash来解决下这个问题。我先验证下这个问题，后续给您反馈哈。
1赞