在 Cassandra 中，TTL（Time-To-Live）作用于单个单元格（cell），而非整行；若仅更新部分列并指定 TTL，只有被 SET 的列获得新 TTL，其余列保留原有 TTL 或无 TTL，导致后续读取时部分字段返回 NULL。正确做法是显式更新所有需保留的列并统一应用 TTL。
在 cassandra 中，ttl（time-to-live）作用于单个单元格（cell），而非整行；若仅更新部分列并指定 ttl，只有被 `set` 的列获得新 ttl，其余列保留原有 ttl 或无 ttl，导致后续读取时部分字段返回 null。正确做法是显式更新所有需保留的列并统一应用 ttl。
Cassandra 的数据模型决定了 TTL 是列级（per-cell）语义，不存在“整行 TTL”这一概念。当你执行如下语句：
QueryBuilder.update(KEY_SPACE, TABLE_NAME) .with(QueryBuilder.set(LAST_ACTIVITY, ts)) .where(QueryBuilder.eq(ENTRY_ID, userA)) .and(QueryBuilder.eq(ID, userB)) .using(QueryBuilder.ttl(ttl));
USING TTL xxx 仅作用于本次 SET 操作涉及的单元格（即 LAST_ACTIVITY 列），而该行中其他列（如 created_at、status 等）的 TTL 不受影响——它们仍维持原始写入时的 TTL（或永不过期）。若干秒后，未更新的列可能已过期，查询时返回 NULL，造成数据不一致。
✅ 正确方案：显式重写所有需要保留有效性的列，并为每一列应用相同 TTL。例如，假设目标表包含 entry_id, id, last_activity, created_at, version 五列，且你希望整行统一拥有 ttl 秒有效期，则应：
private Statement updateWithFullRowTTL(int ttl, Long ts, Long createdAt, Integer version) {
return QueryBuilder.update(KEY_SPACE, TABLE_NAME)
.with(QueryBuilder.set(LAST_ACTIVITY, ts))
.and(QueryBuilder.set(CREATED_AT, createdAt))
.and(QueryBuilder.set(VERSION, version))
// 注意：主键列（entry_id, id）不可 SET，但非主键列必须全部显式覆盖
.where(QueryBuilder.eq(ENTRY_ID, userA))
.and(QueryBuilder.eq(ID, userB))
.using(QueryBuilder.ttl(ttl)); // 此 TTL 同时应用于所有 .set() 的列
}⚠️ 关键注意事项：
- 主键列（PARTITION KEY 和 CLUSTERING COLUMN）不能被 SET，它们由 WHERE 子句定位，其值不可变更（除非使用 UPDATE ... SET pk = ... 配合 DELETE + INSERT，但不推荐）；
- 所有非主键列（即普通列）若需保持有效且同步过期，必须全部出现在 .with(...).and(...) 链中，并共享同一 USING TTL；
- 若某些列允许“自然过期”或无需 TTL 控制，可选择不更新它们——但务必意识到这将导致行内 TTL 不一致；
- 使用轻量级事务（IF EXISTS）或 BATCH 无法改变 TTL 的列级本质，仅能保证原子性。
? 进阶建议：若业务频繁要求“整行 TTL 语义”，可考虑在应用层封装工具方法，自动读取当前行非空值（通过 SELECT），再生成含全部列的 UPDATE ... USING TTL 语句；或改用物化视图 + TTL 策略（需谨慎评估一致性开销）。但最可靠、低延迟的方式仍是明确声明所有需保鲜的列。
总之，Cassandra 中没有魔法般的“行级 TTL”，只有严谨的列级 TTL。理解并遵循这一设计约束，是写出健壮、可预测数据操作逻辑的前提。
