DynamoDB中SQL Triggers替代方案与滑动窗口列表触发实现

DynamoDB 没有和 SQL CREATE TRIGGER 完全等价的原生表级内置触发器，要实现列表属性的滑动窗口自动截断，可以根据你的场景选下面两种成熟方案：

这个方案不需要任何后置组件，逻辑直接在DynamoDB服务端原子执行，和你要的触发器效果完全一致，延迟为0，也不存在并发冲突问题。
核心是利用DynamoDB更新表达式的list_append列表拼接能力+负索引切片能力，在追加新元素的同时直接完成截断，不需要先读取当前列表内容再回写。
假设你的滑动窗口固定保留N个最新元素（比如N=10），列表属性按「最早元素在前、最新元素在后」的顺序存储，更新请求直接写如下逻辑即可：

UpdateExpression: "SET #slidingWin = list_append(if_not_exists(#slidingWin, :emptyList), :newItem)[-:windowSize]",
ExpressionAttributeNames: {
  "#slidingWin": "你的滑动窗口列表属性名"
},
ExpressionAttributeValues: {
  ":emptyList": [],
  ":newItem": ["你要追加的新元素"], // 注意list_append要求两个参数都是列表，单元素要包一层数组
  ":windowSize": 10 // 替换为你实际需要的窗口长度
}

这个写法的逻辑是：

1. 如果列表属性不存在，自动初始化为空列表
2. 把新元素追加到列表尾部
3. 直接截取列表最后windowSize个元素作为新值
   不管当前列表长度是多少，这个逻辑都能自动适配：列表长度没到窗口阈值时不会丢元素，长度达到阈值后每追加一个新元素，就自动丢弃最开头最早存入的元素，完全符合滑动窗口要求。

这个方案的限制是需要所有写入该列表属性的请求都使用这套更新逻辑，如果有写入方绕过规则直接覆盖全量列表，会破坏滑动窗口约束。

如果你的表有多个不可控的写入来源（比如其他服务导入、控制台手动修改、第三方工具写入等），没法统一约束写入逻辑，可以用DynamoDB原生的变更流能力实现和SQL触发器完全对齐的效果：

1. 给目标表开启DynamoDB Streams，流记录配置为「包含新旧镜像」模式，确保能拿到修改前后的属性值
2. 绑定Lambda函数作为流消费者，批处理大小可根据实时性要求设置为1-100，函数核心逻辑：
   • 遍历每条流变更记录，筛选出涉及滑动窗口列表属性修改的新增/更新事件
   • 读取修改后的列表长度，判断是否超过你设置的窗口阈值
   • 如果超过阈值，发起一次更新请求，截断列表保留最后N个元素，丢弃最早的元素
   • 注意做幂等判断（比如判断当前列表长度是否已经符合要求，避免Lambda重复消费流记录导致重复截断）
3. 给Lambda配置对应表的读写权限即可正常运行

这个方案的优缺点：

• 优势：完全不限制写入方式，只要表中数据变更就会触发逻辑，和SQL触发器的行为一致
• 劣势：有几百毫秒到1秒左右的触发延迟，截断是后置操作，存在极短时间窗口内列表长度超过阈值的情况；需要额外维护Lambda资源，会产生少量的流读取和函数调用成本

不要采用客户端先读列表、计算截断后再写回的读改写模式，也不要用DynamoDB事务包裹这类逻辑，并发写入场景下极易出现冲突覆盖，性能和成本表现都远差于上面两种方案。

内容的提问来源于stack exchange，提问作者Manas Singh