您在问题中提出的命令做出了几个不正确的假设。首先，“修复”不应该也不会节省任何空间。修复所做的就是找到不同副本之间的不一致并修复它们。它要么什么都不做（如果没有不一致），要么添加数据，而不是删除数据。其次，“清理”是在将新节点添加到集群后需要做的事情——在每个节点将其一些数据发送到新节点之后，“清理”会从旧节点中删除数据。但是不添加节点时清理不相关。
您可能正在寻找的命令是“紧凑”。这可以节省空间，但前提是您知道有很多覆盖（重写现有行）、删除或数据过期 (TTL)。你使用什么压缩策略？如果它是默认的大小分层压缩策略（STCS），您可以启动主要压缩（nodetool compact），但应该注意涉及的大风险：
主要压缩将所有数据合并到一个 sstable（Cassandra 的磁盘文件格式）中，删除已删除、过期或覆盖的数据。但是，在此压缩过程中，您同时拥有输入和输出文件，在最坏的情况下，这可能会使您的磁盘使用量翻倍，并且如果磁盘已满 50% 以上可能会失败。这就是为什么许多 Cassandra 最佳实践指南建议永远不要填充超过 50% 的磁盘。但这只是最坏的情况。如果您知道输出文件将比输入文件小得多（因为大部分数据已被删除），那么您可以使用更少的可用空间。也许更有用的是，如果您有许多单独的表（列族），您可以单独压缩每个表（按照您的建议，从最小到最大），并且在压缩期间临时所需的最大磁盘空间量可能远小于 50%的磁盘。
Scylla 是 Cassandra 的 C++ 重新实现，正在开发一种称为“混合压缩”的东西（参见https://www.slideshare.net/ScyllaDB/scylla-summit-2017-how-to-ruin-your-performance-by-choosing -the-wrong-compaction-strategy ) 类似于 Cassandra 的 size-tiered compaction，但会以小块的形式进行压缩，而不是生成一个大文件，以避免在压缩期间使用大量临时磁盘。不幸的是，Cassandra 还没有这个功能。
好主意是首先在最小键空间上的最小表上开始修复并完成修复。这将需要时间，但更安全的方式，没有机会挂起和交通损失。修复完成后，以与修复相同的方式开始清理。这样对节点和集群也没有影响。
你不应该填充超过 50-60% 的磁盘来为压缩腾出空间。如果您的磁盘使用量超过该数量，则需要考虑获得更大的磁盘或添加更多节点。
Datastax 建议通常很好遵循：https ://docs.datastax.com/en/dse-planning/doc/planning/planPlanningDiskCapacity.html