在AWS DynamoDB中实现offset和limit功能的最优方法是什么？

DynamoDB原生没有提供类似SQL的offset能力，核心原因是offset需要扫描跳过前N条数据，在分布式存储架构下会带来极高的性能和成本开销，你当前的实现本质是扫描所有匹配查询条件的记录再截断，offset越大消耗的读容量越高，完全不可扩展，以下是可落地的优化方案：

方案1：排序逻辑对齐排序键（SK），用LastEvaluatedKey替代offset（优先推荐） #

你当前的查询是按固定分区键（PK）查询，同一个PK下的所有数据默认是按排序键（SK）有序存储的，如果你业务需要的排序规则可以和SK的排序规则对齐，可以完全放弃offset：

• 提前定位到offset对应记录的SK值，将该记录的完整主键作为exclusiveStartKey传入查询请求
• 直接设置查询的limit参数为你需要的返回条数，DynamoDB只会扫描limit对应的记录数，不会消耗额外读容量

优化后的代码示例：

Map<String, AttributeValue> valueMap = new HashMap<>();
valueMap.put(":v1", new AttributeValue().withS(id));

Map<String, String> nameMap = new HashMap<>();
nameMap.put("#PK", "PK");

DynamoDBQueryExpression<TestClass> expression = new DynamoDBQueryExpression<TestClass>()
    .withKeyConditionExpression("#PK = :v1")
    .withExpressionAttributeNames(nameMap)
    .withExpressionAttributeValues(valueMap)
    .withConsistentRead(false)
    // 传入offset对应的记录主键作为起始键
    .withExclusiveStartKey(offsetStartKey)
    // 直接设置需要的返回条数
    .withLimit(limit);

PaginatedQueryList<TestClass> testList = dynamoDBMapper.query(TestClass.class, expression);
// 此时返回的第一条就是offset对应的记录，直接取前limit条即可
return testList.subList(0, limit);

方案2：用GSI适配自定义排序规则，配合缓存预存偏移键 #

如果业务排序字段不是SK，可以创建全局二级索引（GSI）：

• 将查询的PK作为GSI的分区键，业务需要排序的字段作为GSI的排序键
• 增加缓存层（如Redis），按查询PK维度预存每N条记录的主键，比如每100条存一个对应的LastEvaluatedKey，查询时先取最近的预存键作为起始点，最多只需要扫描N条记录即可拿到目标offset的数据，大幅降低读容量消耗

方案3：同步数据到专门的查询存储 #

如果业务需要支持任意动态排序、大offset查询，无法适配SK/GSI规则，可以用DynamoDB Stream将数据增量同步到Elasticsearch、RDS等支持offset分页的存储，复杂查询走同步后的存储，DynamoDB仅承担增删改和KV级别的简单查询，这个方案需要额外维护同步链路，但适配性最强。

临时优化方案（不改架构的前提下） #

如果你暂时无法调整现有架构，可以修改现有查询逻辑，手动设置查询的limit参数为offset + limit，不要用boundedIterator遍历全量：

DynamoDBQueryExpression<TestClass> expression = new DynamoDBQueryExpression<TestClass>()
    .withKeyConditionExpression("#PK = :v1")
    .withExpressionAttributeNames(nameMap)
    .withExpressionAttributeValues(valueMap)
    .withConsistentRead(false)
    // 只查询offset+limit条，避免扫描全量
    .withLimit(offset + limit);

PaginatedQueryList<TestClass> testList = dynamoDBMapper.query(TestClass.class, expression);
if (testList.size() <= offset) {
    return Collections.emptyList();
}
int end = Math.min(testList.size(), offset + limit);
return testList.subList(offset, end);

这个方案虽然还是要扫offset条数据，但相比扫描全量匹配的记录，读容量消耗已经大幅降低，适合offset不大的业务场景。

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