我认为 Cassandra 4.1.7 表中的墓碑不会被删除。
该表的 gc_grace_seconds = 345600
即使在运行之后nodetool garbagecollect（删除后远晚于 4 天），如果我运行，nodetool tablestats我会得到以下结果：
执行垃圾收集后，磁盘大小也不会减少。
我不确定我过去是否跑过nodetool compact（我想这意味着我需要继续使用它？）
附带问题，如何让 tablestats 返回更新的信息（而不是从 2024-12-12 开始）
谢谢
听起来好像压缩没有运行。这很糟糕，但即使手动运行一次，也会出现这种情况。
尝试运行
SELECT * FROM system.compaction_history。如果有问题的 keyspace.table 有一段时间没有运行，您可能需要开始安排它定期运行。压缩该表后，请
nodetool tablestats再次查看。如果没有显著改善，那么这里可能存在其他问题。编辑 20241223
我还是不会跑
nodetool compact。是否启用了快照？如果压缩确实在运行，则旧快照可能与一个或多个 SSTable 有硬链接。如果是这样，请查看清理一些旧快照，然后查看压缩是否会自行再次运行。
该
nodetool garbagecollect命令专门用于从表中删除已删除的数据，不一定是墓碑数据。这里要注意的是，如果删除了整个分区，墓碑将被删除
garbagecollect。我认为这不适用于您的情况，因为看起来您正在删除分区内的行。行墓碑不一定会被删除，特别是如果分区的片段仍然存在于其他 SSTable 中。您发布的屏幕截图显示了包含数百万行墓碑的分区。这表明您正在使用 Cassandra 来管理队列，并在处理完条目（行）后将其删除。
队列和类似队列的数据集不适合 Cassandra，因为它们积累了太多的墓碑（请参阅博客文章队列是一种反模式）。对于您来说，您手动触发压缩作为一种解决方法，但这会产生其他问题，正如我在另一篇文章中解释的那样（请参阅为什么强制进行主要压缩并不理想）。
短期内，除了继续做你正在做的事情，你真的没有太多选择。长期解决方案是审查你的用例并可能重新设计你的数据模型。干杯！