一个简短的TTL是不好的原因是你打开自己阅读一吨墓碑。大多数人在阅读大量墓碑时会做什么，他们会放弃gc_grace_seconds，这就为可能的数据复活打开了大门。
一个有效的，或者说好的TTL应该是一个有助于解决你所涵盖的任何问题的TTL，但也要考虑到如果我读了这些数据，我会读200个墓碑还是20，000个墓碑。如果你从来没有读回数据，那么它可能不会有任何关系，除了你可能会占用大量的物理磁盘删除的数据。

使用TTL写入数据时，会发生两件事：
1.将数据插入到表中，并且
1.插入标记数据以便在将来的日期删除的墓碑。
由于Cassandra具有分布式架构，节点之间没有任何共享，因此管理删除有点复杂。Cassandra将tombstones存储在内存中，这样当应用程序请求数据时，协调器将不会返回已经过期的数据。
如果群集很忙碌，TTL非常低意味着内存中的墓碑会迅速堆积，这会严重影响群集的性能。
此外，如果表具有集群列（每个分区包含1个或多个行），Cassandra可能必须迭代大量已删除的行，然后才能到达活动的行（取决于您的数据模型）。这可能导致逻辑删除压倒异常并导致请求超时。
我建议您看一下How data is deleted in Cassandra，以便更好地了解这个主题。干杯！

根据我自己在网上找到的答案
由于数据库的分布式特性，将TTL（生存时间）设置为仅一秒可能会导致Cassandra中出现意外行为。当数据以一秒的TTL写入Cassandra节点时，它会在该时间过后立即被标记为删除。但是，将此删除传播到群集中的所有节点可能需要一些时间，这可能导致数据不一致。
在这种情况下，似乎集群中的一些节点可能在其他节点之前接收到删除信号，导致一些记录被删除，而其他记录没有被删除。这可能导致只保留主键字段，而其余数据为空的情况。
Cassandra中TTL的安全值取决于特定的用例和数据保留要求。通常，建议使用至少几分钟的TTL值，以便有足够的时间将删除信号传播到群集中的所有节点。