AWS DAX执行table.scan()全表扫描性能劣于原生DynamoDB问题咨询

DAX从设计上就不是为全表Scan场景优化的，你观察到的Scan变慢、GetItem变快是完全符合产品预期的表现：

• DAX的缓存加速能力仅对按主键精准匹配的请求（GetItem、带明确分区键条件的Query）生效，Scan请求无论对应数据是否在DAX缓存中，都会被完整转发到后端DynamoDB源站执行，不会直接从缓存返回结果，自然拿不到缓存加速的收益。
• DAX作为代理层，所有Scan请求会多一层代理转发、跨节点序列化/反序列化的开销，万级记录的结果集体量下，这部分额外开销完全超过了DAX能提供的任何潜在收益，所以耗时比直连DynamoDB高是正常现象。
• 你贴的测试代码本身存在分页逻辑bug：循环中仅给scan_args变量赋值了ExclusiveStartKey，但调用table.scan()时根本没有传入这个参数，实际每次循环都在重复扫描表的第一页数据，并没有完成真正的全表遍历，测出来的耗时数据本身存在偏差。

• 第一步先修复测试代码的分页逻辑，修正后的可复现代码如下：

import time
import amazondax

daxclient = amazondax.AmazonDaxClient.resource(endpoint_url="替换为你的DAX集群端点")
table = daxclient.Table("替换为你的表名")
start_time = time.perf_counter()
all_items = []
scan_params = {}

while True:
    try:
        resp = table.scan(**scan_params)
        all_items.extend(resp.get("Items", []))
        if "LastEvaluatedKey" not in resp:
            break
        scan_params["ExclusiveStartKey"] = resp["LastEvaluatedKey"]
    except Exception as e:
        print(f"扫描异常: {e}")
        break

print(f"扫描完成，总记录数{len(all_items)}，耗时{time.perf_counter() - start_time}秒")

• 连续执行两次全表Scan，如果第二次耗时和第一次没有明显差距，即可确认Scan请求完全没有命中DAX缓存，所有请求均回源到DynamoDB执行。
• 检查DAX集群的节点规格、部署可用区：如果DAX节点CPU/网络带宽打满、和Lambda所在可用区跨区，会进一步放大Scan请求的延迟，但这不是Scan变慢的核心原因。

• 全量加载表数据的场景直接放弃用DAX执行Scan，直连DynamoDB原生端点做Scan即可，DAX仅用于承载业务运行过程中的点查、索引查询请求，匹配它的设计优化场景。
• 针对万级记录的全表加载场景，可以用以下方式进一步压缩耗时：
  • 开启并行Scan，将TotalSegments参数设置为Lambda分配的vCPU数（比如分配1G内存对应0.5vCPU就设为1，2G以上对应1vCPU就设为2），多线程并行扫描分段数据，万级记录的扫描耗时可以压缩到10秒内。
  • 配置ProjectionExpression参数，仅加载业务实际需要的字段，减少网络传输的数据量。
  • 如果全表加载是Lambda冷启动阶段的逻辑，可以将加载后的全量数据缓存到Lambda临时存储、ElastiCache中，避免每次冷启动都重复扫描全表。
• 不需要在DAX层做Scan性能调优，DAX官方明确不保证Scan类操作的性能提升，大结果集Scan场景下代理层的额外开销必然会导致延迟高于直连。

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