Union all 并发查询速度问题

我直接修改 numOfVnodeQueryThreads这个参数为4先试试看? 先不改vgroups数量。
如果单机spllit修改某个vgroups数量从9改成18或者36(2-4倍),那这个库占单机的磁盘的空间是不是也变成2-4倍了?

开源版本不支持split vgroup的功能。
磁盘空间会短暂翻倍,后台会进行compact,所以执行前需要保证足够空间。

建议先观察下语句执行时cpu多核的负载情况,看情况调整numOfVnodeQueryThreads

32核cpu整体在15% 到50%之间跳动。如果语句没有其它优化。我先把numOfVnodeQueryThreads参数改成4后重启. 后续观察运行情况再来反馈,多谢

1600万给子表,每天主要拿其中200万个子表最近一两天数据进行计算。 改了numOfVnodeQueryThreads为4后,速度可能快了20%,改善不是很大。 高并发会经常报错以下错误,有时候会查不出来。但是失败语句拿出来单独执行又是秒出结果
he request was canceled due to the configured HttpClient.Timeout of 30 seconds elapsing

高峰读写并发高会报 timeout错误。如果把服务器硬盘从机械硬盘换成固态硬盘速度会快很多吗?

如贴子的图这样 union all 改成 in 的方式 高并发情况下会好一些吗? 单个语句in 是比union all慢一些. 我想这 union all 是不是占cpu多一些.高并发反而慢?

云服务器是虚拟机,查看磁盘类型语句不准,实际上是固态硬盘