首先，我不会更改cassandra-env.sh中的参数，而是使用jvm.options文件。
其次，我可能不会移动到128 G堆大小，这可能太大了。
第三，newsize和max heap size应该相同，否则，你会得到扩展，这可能会导致性能问题。
第四，在增加堆大小之前，您必须了解发生了什么。为什么要增加堆大小？您是否看到由于堆耗尽而导致的分配错误？您是否看到长时间的旧一代GC暂停？
在jvm.options中，设置-Xmx和-Xms，而不是乱用cassandra-env.sh。

我真的不认为堆设置是这里的问题。史蒂夫是正确的，你肯定不想去128 GB。事实上，我不建议去32 GB以上的w/ Java 8。他也是正确的，在堆配置更改与Cassandra 4应该在jvm.options文件，而不是cassandra-env.sh。
这个问题是这样的：

select col1,col2,col3..col75 FROM keyuspace.table
WHERE "ID" in (65893388252433)
AND "EndTime" >= 1688511600000 AND "EndTime" <= 1688597999999
LIMIT 20000 ;

字符串
我们在表中总共有200列，它需要大约45秒来填充20 k记录。如果我们在“in子句”中选择多个ID，它需要很多时间，有时会挂起。
根据上面的SELECT语句判断，我猜PRIMARY KEY定义看起来像这样：PRIMARY KEY (("ID"),"EndTime)。在我看来，它也像是你试图一次拉回太多的数据。我建议如下：

• 一次只能查询一个"ID"。
• 对于SELECT中指定的列数要谨慎。
• 减少时间窗口。看起来这个查询是24小时;看看你是否可以降低它。
• 重新构建表，使用“hour”作为分区桶;例如：PRIMARY KEY (("ID","hour_bucket"),"EndTime")。这将导致更小的分区，这看起来也是一些问题。
• 使用固态驱动器。不确定此群集背后的磁盘硬件，但我愿意打赌磁盘IO延迟太高。如果群集没有固态驱动器支持，这将是最大的性价比。如果群集在云中，请考虑迁移到下一个磁盘层。如果群集磁盘由RAID或其他磁盘阵列设备抽象，检查以确保集群中节点的磁盘没有被放置在同一个硬件阵列中。很有可能查询遇到了不受Cassandra影响的磁盘瓶颈。