一次创建这么多分区确实是会很慢的。
Failed to flush data to StarRocks. 有具体报错的。出现的话可以在论坛提新的帖子。
delete目前效率不太好，集群有很多删除吗？这个队列是排队的，失败也不会取消任务，也是一直排队，所以删除的时候一定要指定分区去删，不然一堆任务会给每个be都发大量删除任务占用队列，前面没指定分区删的话，他会发大量删除任务，即使删除失败了，这些任务也没有cancel掉，导致后面的新的任务也会失败掉
整表删除、删数据库也会造成这样的情况吗，我有操作整表删除，删数据库
drop/truncate的话不会，delete跟drop机制不一样。
我几乎没有进行delete操作，都是drop/truncate，看be CPU Idle也处于85%左右，可是建表和truncate用时都非常久，但是确实又能成功，其他的查询又是正常的1s左右，我不知道问题出在哪
当前使用的是哪个版本？
2.2.0 1fe+3be 16核+64G
这些操作是fe的操作，可以看下fe.conf里的jvm大小是多少，你这个很可能是fe压力比较大了，可以适当调大jvm的大小并重启fe看看。
jvm调大了之后（8g->16g）我进行了简单的测试，调大之后依然需要很久，即使是一个空表，虽然分区有331个，但是也不算很多吧，而且都是空的，问题应该是其他原因导致的。
在等待命令"TRUNCATE TABLE
common_asset_info_0606_copy2 "完成的时候，我对一个没有分区的简单表执行清空命令，出现如下报错，当上面的命令完成之后，下图里的命令很快就完成了不报错，首先是报错语句是创建表超时，但我只是执行清空表命令，其次两个清空命令为什么不能同时执行呢？
目前truncate原理是创建新的空tablet,认后再swap。这331个分区每个分区设置的bucket是多少？默认3副本可以算下总共的tablet数量。如果太多的话效率会下降，或者你指定分区去truncate，看下效率
tablet 是23,832，243331，5s的那次还算正常，4min就不正常了，即使tablet多效率下降，4min肯定也是不正常的
因为这里是队列排队，所以可能是前面有任务积压导致的，这块我们在优化，目前的话可以在ddl操作的时候规划一下，不要同时做很多类似的操作，另我们建议单tablet数据量大概在100MB-1GB之间，单表这么多tablet还是根据数据量早点规划下合理的tablet数值，tablet太多查询和写入性能都不好
好的，谢谢解答，因为数据比较分散，分区不是很方便划分，造成了tablet虽然多但是大部分都是空的，这会对性能造成影响吗
小文件影响挺大的，尤其是不指定分区去做一些元数据操作的时候，对fe压力挺大，如果天级别数据量小，可以按月或者年去分，以及减少单分区的bucket数量，按照这些思路去规划下建表。
我发现只有主键模型建表慢，更新模型，明细模型，不论我分区多少，几秒就好了，主键模型分区少一点，也要几百秒，请问是什么原理呢
有建表语句么，我复现下？
大佬还有关注这个问题吗@Natsume729