Cassandra通過寫一條“tombstone”來標記一個數據被刪除了。被標記的數據默認要10天(配置文件中的gc_grace_seconds)后且被compaction或cleanup執行到對應的SSTable時才會被真正從磁盤刪除，因為如果當時這個delete操作只在3個節點中的2個執行成功，那么一旦2個有tombstone的節點把數據刪了，集群上只剩下沒tombstone的那個節點，下次讀這個key的時候就又返回對應的數據，從而導致被刪除的數據復活。Repair操作可以同步所有節點的數據從而保證tombstone在3個節點中都存在，因此如果想確保刪除100%成功不會復活需要以小於gc_grace_seconds的周期定期執行repair操作(所以官方建議”weekly”)。
然而在select數據的時候，在每個SSTable遇到的所有符合查詢條件的tombstone要放內存中從而在合並每個SSTable文件的數據時判斷哪些column數據沒被刪能最終返回，tombstone太多會導致heap被大量占用需要各種GC從而影響性能，所以cassandra默認讀到100000個(可配置)tombstone就強制取消這次讀取，因為遇到這種情況一定是你“doing it wrong”。因此如果經常刪除一個row key下的column key，同時又有一次select一個row key下多個column key的需求，很容易遇到這種情況，tombstone很多的時候即使不到10w最終成功讀取了，這次讀取也會很慢，並很快導致觸發年輕代GC從而拖慢整個節點的響應速度。
最好的解決方案肯定是設計的時候就避免。但假如在不修改表結構的情況下，解決方案有兩種：如果不能接受一個column key被刪又復活，先把gc_grace_seconds改成0，然后刪除的時候用ALL模式，當然只要有1個節點超時/掛掉刪除就會失敗；如果能接受被刪的數據復活，刪除只為了減少磁盤空間使用，那就直接把gc_grace_seconds設成0，復活就復活吧。