DynamoDB 支持 TTL 吗？

支持。DynamoDB 支持 Time to Live（TTL）。你指定一个存放 Unix 纪元过期时间戳（以秒为单位）的 Number 属性；DynamoDB 随后会在后台移除过期项——通常在过期后的几天内——不额外收费，也不消耗写容量。已过期但还没被删掉的项，在被移除之前仍可能出现在读取结果里。

怎么启用

为这张表打开 TTL，并指明存放过期时间的那个属性。那个属性必须是 Number，存的是以秒为单位的 Unix 纪元时间戳（不是毫秒）。值已经在过去的项就有资格被删除。

该有什么预期

免费——自动删除不消耗写容量单元。自己做同样的清理，每个项要花一个写单元：一千万个过期的 1 KB 项就是一千万个写单元，在 us-east-1 按需模式下是 $6.25，再加上为了找出它们而对一张 100 GB 的表做一次全表扫描的大约 $1.64。（一个例外：在全局表上，复制到其他每个区域的那次删除，在当地确实会消耗复制写容量。）
不是即时的——DynamoDB 通常在项过期后的几天内把它移除。
仍然可读——在被物理删除之前，过期项仍可能出现在读取、查询和扫描中，所以如果精确性重要，就把它们过滤掉。

它悄无声息永不触发的那种方式

DynamoDB 不会校验你指给 TTL 的那个属性。下面两次写入，在一张 TTL 指向 expiresAt 的表上都返回了 HTTP 200，而这两个项永远不会过期：

{"pk": {"S": "sess#1"}, "expiresAt": {"S": "1790812800"}}
{"pk": {"S": "sess#2"}, "expiresAt": {"N": "1790812800000"}}

第一个把时间戳存成了 String。AWS 明确写着 "items with a TTL attribute that is not a Number type are ignored by the TTL process"，而无论在写入时、启用时还是之后，都没有任何东西提醒你。

第二个才是真正会发生的那个，因为类型是对的，而值来自 Date.now()。1790812800000 是 2026 年 10 月 1 日的毫秒数。按秒来读——而 TTL 只会按秒来读——那个时间戳落在公元 58718 年。这个项格式良好、可查询、按存储计费，并且计划在五万六千年后过期。

API 里没有任何东西会暴露这两种错误，所以检查只能发生在你写入之前。我们的 TTL 转换器正是为此把任何大于 1e12 的值都当作毫秒，并把该值解析出来的日期显示给你。

常见用途

会话记录、验证令牌，以及应当自我清理的缓存结果——都是经典的 TTL 用例。搭配 DynamoDB Streams 就能对删除做出响应。

深入了解

阅读 DynamoDB TTL 指南和 DynamoDB Streams。下载 DynoTable 来查看和设置 TTL 属性。

参考资料

最后核实于 2026-07-13，依据上方链接的 AWS 官方文档；TTL.html 于 2026-07-28 重新核对。

上面两次写入是 2026-07-28 通过 @aws-sdk/client-dynamodb 3.1095.0 针对 DynamoDB Local 3.3.0 运行的，都以 HTTP 200 被接受。清理成本按我们同步的 AWS 定价表中的 us-east-1 按需费率计算。