你在问题中提出的命令有几个错误的假设。首先，“修复”不应该，也不会，节省任何空间。修复所做的一切就是发现不同副本之间的不一致并修复它们。它要么什么都不做（如果没有不一致），要么添加数据，而不是删除数据。第二，“清理”是在向集群中添加新节点之后需要执行的操作—在每个节点将其部分数据发送到新节点之后，“清理”将从旧节点中删除数据。但在不添加节点时，清除不相关。
您可能需要的命令是“compact”。这可以节省空间，但只有当您知道您有大量的覆盖（重写现有行）、删除或数据过期（ttl）时。你在使用什么压缩策略？如果是默认的大小分层压缩策略（stcs），则可以启动主要压缩（nodetool compact），但应注意所涉及的巨大风险：
主要压缩将所有数据合并到一个sstable（cassandra的磁盘文件格式），删除已删除、过期或覆盖的数据。但是，在此压缩过程中，您同时拥有输入和输出文件，在最坏的情况下，这可能会使磁盘使用率翻倍，并且如果磁盘已满50%以上，则可能会失败。这就是为什么许多cassandra最佳实践指南建议永远不要填充超过50%的磁盘。但这只是最坏的情况。如果您知道输出文件将比输入文件小得多（因为大部分数据已被删除），那么您可以使用更少的可用空间。也许更有用的是，如果您有许多单独的表（列族），您可以分别压缩每个表（如您所建议的，从最小到最大），并且压缩过程中临时需要的最大磁盘空间量可以远远小于磁盘空间的50%。
“锡拉”，Cassandra的c++重新实现，正在开发一种被称为“混合压实”（参见https://www.slideshare.net/scylladb/scylla-summit-2017-how-to-ruin-your-performance-by-choosing-the-wrong-compaction-strategy)这就像cassandra的大小分层压缩，但它只压缩小块而不是生成一个巨大的文件，以避免压缩过程中使用大量临时磁盘。不幸的是，Cassandra还没有这个功能。

好主意是首先开始修复最小表上的最小键空间，然后逐个完成修复。这将需要时间，但更安全的方式，没有机会挂和交通损失。修复完成后，以与修复相同的方式开始清理。这样对节点和集群也没有影响。

你不应该填充超过50-60%的磁盘来为压缩腾出空间。如果您的磁盘使用量超过这个数量，您需要考虑使用更大的磁盘或添加更多的节点。
税务建议通常很好遵循：https://docs.datastax.com/en/dse-planning/doc/planning/planplanningdiskcapacity.html