Java中DynamoDB查询如何通过本地二级索引按score排序结果

所有Query请求的返回结果，只能按照当前查询的表/索引的排序键做升序/降序排列，不支持自定义指定其他字段排序。
键条件（KeyCondition）仅支持对分区键、当前查询目标的排序键设置匹配规则，其余属性的条件都属于过滤条件（Filter），过滤是在数据检索完成后、结果返回前做的内存筛选，不会改变结果排序，也不会减少底层实际扫描的数据量。

对应你当前的表结构：

• 基于isEligible建的LSI（本地二级索引），排序键是isEligible，查询该索引时结果只能按isEligible+基表排序键user_id排序，无法按score排序
• 基于score建的LSI，排序键是score，天然支持按score排序，但isEligible不是该索引的键字段，无法通过键条件做前置过滤，只能做后置过滤

方案1：小结果集场景（无需改表，开发成本最低） #

适用场景：单个reference_number分区下总数据量较小（千级以内，单次Query可拉取完成），对读容量消耗不敏感。
直接查询score字段对应的LSI：

• 键条件仅指定分区键reference_number等于目标值
• 过滤条件设置isEligible = true
• 通过scanIndexForward参数控制score升序/降序，返回结果会自动保留按score排序的顺序，仅过滤掉不符合条件的条目

Java SDK 2.x 实现代码示例：

import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.dynamodb.model.AttributeValue;
import software.amazon.awssdk.services.dynamodb.model.QueryRequest;
import software.amazon.awssdk.services.dynamodb.model.QueryResponse;
import java.util.HashMap;
import java.util.Map;

public class EligibleUserQuery {
    public static void main(String[] args) {
        try (DynamoDbClient ddb = DynamoDbClient.create()) {
            // 替换为实际配置
            String tableName = "你的业务表名";
            String scoreLsiName = "score字段对应的LSI名称";
            String targetRefNum = "要查询的reference_number值";

            Map<String, AttributeValue> expressionValues = new HashMap<>();
            expressionValues.put(":refNum", AttributeValue.builder().s(targetRefNum).build());
            expressionValues.put(":isEligible", AttributeValue.builder().bool(true).build());

            QueryRequest queryRequest = QueryRequest.builder()
                    .tableName(tableName)
                    .indexName(scoreLsiName)
                    .keyConditionExpression("reference_number = :refNum")
                    .filterExpression("isEligible = :isEligible")
                    .scanIndexForward(false) // false为score降序，true为升序
                    .expressionAttributeValues(expressionValues)
                    .build();

            QueryResponse response = ddb.query(queryRequest);
            // 结果集已按score排序，仅包含isEligible=true的条目，直接处理即可
            response.items().forEach(item -> {
                // 填写你的业务处理逻辑
            });

            // 如果结果集超过1MB，需要通过LastEvaluatedKey做分页遍历，避免数据丢失
        }
    }
}

方案2：大数据量生产场景（性能稳定，读容量无浪费） #

适用场景：单个reference_number分区下数据量大，对查询性能、读容量成本敏感。
由于现有表创建完成后无法新增LSI，需要调整索引结构：

1. 写入数据时新增一个拼接属性，比如命名为eligible_score_sort：将布尔值isEligible转为固定字符串（"TRUE"/"FALSE"），拼接#分隔符后，再拼接补前导零到固定长度的score字符串（比如score是0-10000的整数，补零到5位，98分存为"00098"，浮点数需要做对应格式化保证字典序和数值序一致），最终值形如"TRUE#00098"。
2. 新建一个GSI（全局二级索引）：分区键设为reference_number，排序键设为上述新增的eligible_score_sort属性，将业务需要返回的字段投影到索引中。
3. 查询时直接访问该GSI，键条件设置为reference_number = :refNum AND begins_with(eligible_score_sort, "TRUE#")，不需要额外加过滤条件，通过scanIndexForward即可直接拿到按score排序的符合条件的结果，无多余数据扫描，性能稳定。

该方案的Java代码仅需调整键条件表达式、去掉过滤条件即可，逻辑和方案1基本一致。

注意事项 #

• LSI有单分区大小限制：单个分区键下基表+所有LSI的总数据量不能超过10GB，如果单reference_number下数据量可能超过该阈值，优先选择GSI方案。
• 所有Query请求单次最多返回1MB数据，结果集较大时必须通过LastEvaluatedKey做分页轮询，避免数据截断。

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