工作原理：DynamoDB 生存时间（TTL）
在 DynamoDB 表上启用 TTL 时，必须标识此服务在确定项目是否符合过期条件时将查找的特定属性名称。在表上启用 TTL 后，每个分区扫描程序后台进程都会自动持续评估表中项目的过期状态。
扫描程序后台进程将 Unix纪元时间格式Number 数据类型时，属性的值是 Unix 历元时间格式
从表中删除项目时，会同时执行两项后台操作：
-
按照与 DeleteItem 操作相同的方式，从任何本地二级索引和全局二级索引中删除项目。此操作没有任何额外成本。
-
每个项目的删除操作都会进入 DynamoDB Streams，但会被标记为系统删除，而不是常规删除。有关如何使用此系统删除的更多信息，请参阅 DynamoDB Streams 和生存时间。
-
根据表的大小和活动性级别，过期项目的实际删除操作可能会有所不同。由于 TTL 注定是一个后台流程，因此，用于通过 TTL 过期和删除项目的容量实质上是可变的（但是免费的）。TTL 通常在过期 48 小时内删除已过期的项目。
已过期但尚未被 TTL 删除的项目仍会出现在读取、查询和扫描中。如果您不希望结果集中包含过期项目，必须将它们筛选出来。为此，请使用筛选表达式仅返回 TTL 过期值大于纪元格式的当前时间的项目。有关更多信息，请参阅 扫描的筛选表达式。
-
已过期但尚未删除的项目仍可更新，并且将保留对更改或删除过期属性的成功更新。
您可以在 CloudWatch 指标选项卡上监控表的 TTL 速率，并查看删除项目的时间和速率。
生存时间示例
例如，假设一个名为 SessionData 的表可跟踪用户的会话历史记录。SessionData 中的每个项目都由分区键 (UserName) 和排序键 (SessionId) 标识。UserName、SessionId、CreationTime 和 ExpirationTime 等其他属性跟踪会话信息。ExpirationTime 属性设置为表的 TTL 属性（未显示每个项目的所有属性）。
SessionData | |||||
|---|---|---|---|---|---|
| UserName | SessionId | CreationTime | ExpirationTime (TTL) | SessionInfo | … |
| user1 | 74686572652773 | 1571820360 | 1571827560 | {JSON 文档} | ... |
| user2 | 6e6f7468696e67 | 1571820180 | 1571827380 | {JSON 文档} | ... |
| user3 | 746f2073656520 | 1571820923 | 1571828123 | {JSON 文档} | ... |
| user4 | 68657265212121 | 1571820683 | 1571827883 | {JSON 文档} | … |
| user5 | 6e6572642e2e2e | 1571820743 | 1571831543 | {JSON 文档} | ... |
| ... | ... | ... | ... | ... | … |
在本示例中，每个项目在创建时拥有一个 ExpirationTime 属性值。请考虑以下表项目。
SessionData | |||||
|---|---|---|---|---|---|
| UserName | SessionId | CreationTime | ExpirationTime (TTL) | SessionInfo | … |
| user1 | 74686572652773 | 1571820360 | 1571827560 | {JSON 文档} | ... |
在此示例中，项目 CreationTime 设置为协调世界时 (UTC) 2019 年 10 月 23 日（星期三）上午 08:46，ExpirationTime 设置为 UTC 2019 年 10 月 23 日（星期三）上午 10:46 后 2 小时。该项目将在纪元格式的当前时间大于 ExpirationTime 属性中的时间时过期。在这种情况下，键为 { Username: user1, SessionId:
74686572652773} 的项目将在上午 10:46 (1571827560) 过期。