通过存留时间 (TTL)，您可以设置政策来定期删除 Spanner 表中的数据。移除不需要的数据：
- 降低存储空间和备份费用。
- 减少数据库扫描某些查询的行数，从而可能提高查询性能。
- 有助于遵守限制某些类型的数据的保留期限的法规或行业准则。
TTL 是常规清理活动的理想选择。它在后台持续运行，定期批量删除符合条件的数据。数据通常会在失效日期后的 72 小时内删除。当数据符合删除条件时，TTL 不会立即使数据失效或使其不被查询隐藏。TTL 在插入数据时也不会检查数据，因此不会阻止您插入时间戳已过期的行。
TTL 的设计能够最大限度地减少对其他数据库活动的影响。它比最终用户查询更有效地并行工作，并且包括重试逻辑，以确保进行端到端清理。
另一个后台压缩过程通常在七天内从已删除的行回收存储空间。
TTL 的工作原理是什么？
您可以通过在数据库架构中定义行删除政策，在 Spanner 表上设置 TTL，从而允许 Spanner 定期删除不需要的数据。每个表都可以有自己的政策。每个表只能指定一个 TTL 政策。您可以为 GoogleSQL 方言数据库和 PostgreSQL 方言数据库设置不同的 TTL。
通过 GoogleSQL 使用 TTL
使用 GoogleSQL，您可以通过指定时间戳和间隔来定义行删除政策，以确定某行何时可以删除；例如，上次更新时间加上 30 天。
后台系统进程每天都会检查符合条件的行。它将并行执行的实际删除并行执行，这些删除接近数据存储位置。每个批次都会以一致的时间戳在自己的事务中运行。因此，给定批次中的行以及所有索引和交错子项一定会以原子方式删除。但是，跨批次的删除操作发生在不同的事务中。
由于这是一个异步后台过程，因此从延迟到等待符合标准为止。延迟时间通常少于 72 小时。因此，行可能会在 TTL 到期后在表中保留最多三天；例如，具有行删除政策并删除超过四天的行的表可能包含存在时间不超过 7 天的行，以及较早、不可删除的行。
如需有关如何创建 GoogleSQL 行删除政策的分步说明，请参阅创建 TTL 政策。
TTL 与 PostgreSQL
使用 PostgreSQL，数据库所有者可以在 CREATE TABLE 或 ALTER TABLE 语句中使用 TTL INTERVAL 子句来定义行删除政策。
如需针对 PostgreSQL 表设置行删除政策，该表必须包含一个数据类型为 TIMESTAMPTZ 的列。TTL INTERVAL 子句使用此列设置有关何时可以删除行的间隔规范。
子句的计算结果必须为整数天数。例如，允许使用 '3
DAYS'，'4 DAYS 2 MINUTES - 2 MINUTES' 也是如此，但不允许使用 '4 DAYS 3
MINUTES'，并且系统会返回错误。您不能使用负数。
TTL 垃圾回收功能会在后台持续删除符合条件的行。 由于这是一个异步后台流程，因此在符合条件和删除之间会存在延迟。该表可能包含符合 TTL 删除条件但 TTL 尚未完成的行。延迟时间通常不超过 72 小时。
如需了解如何创建 PostgreSQL 行删除政策，请参阅创建 TTL 政策。
备份和 TTL
恢复备份
从备份恢复数据库时，系统会自动删除源数据库上配置的所有行删除政策。这样可以防止 Spanner 在备份恢复后立即删除过期的数据。因此，您需要手动重新配置 TTL。
数据一致性
备份是特定时间点 (version_time) 的一致数据快照。备份可以包含可能符合 TTL 删除条件但 TTL 尚未完成的行。同样，Dataflow 导出作业会按固定的时间戳读取整个表。
审计
TTL 支持通过变更数据流审核其删除操作。变更数据流数据记录（用于跟踪数据库的 TTL 更改）的 transaction_tag 字段设置为 RowDeletionPolicy，并将 is_system_transaction 字段设置为 true。然后，变更流读取器能够过滤掉所有 TTL 记录或除 TTL 记录之外的所有记录，具体取决于其用例。查看使用 Beam 按事务标记过滤的示例。