25）？
" />
dynamodb 的 query 操作必须指定分区键（hash key），无法直接按非索引字段（如 age）条件查询全表；若需实现类似 sql 的 where age > 25，应改用 scan + filterexpression，并注意性能与成本影响。
dynamodb 的 query 操作必须指定分区键（hash key），无法直接按非索引字段（如 age）条件查询全表；若需实现类似 sql 的 where age > 25，应改用 scan + filterexpression，并注意性能与成本影响。
在 DynamoDB 中，“查询非主键字段”是一个常见但易被误解的需求。正如示例中所见：表 people 的主键由 id（分区键）和 age（排序键）组成，此时 Query 只能基于 id 精确匹配 + age 范围筛选（例如 id = "id_1" AND age > 25）。而语句 "SELECT * FROM people WHERE age > 25" 在 DynamoDB 中 无法通过 Query 实现——因为 age 仅作为排序键存在，其查询能力严格依赖于已知的分区键值。
✅ 正确方案：使用 Scan（而非 Query）
当目标字段（如 age）未建模为任何索引的主键组成部分时，唯一可行的原生操作是 Scan，配合 FilterExpression 进行服务端过滤：
func scanDynamoByAge() {
svc := dynamodb.New(session.Must(session.NewSession()))
params := &dynamodb.ScanInput{
TableName: aws.String("people"),
Limit: aws.Int64(100),
FilterExpression: aws.String("age > :v_age"),
ExpressionAttributeValues: map[string]*dynamodb.AttributeValue{
":v_age": {
N: aws.String("25"),
},
},
Select: aws.String("ALL_ATTRIBUTES"),
}
resp, err := svc.Scan(params)
if err != nil {
log.Printf("Scan Error: %v", err)
return
}
log.Printf("Found %d items", len(resp.Items))
for _, item := range resp.Items {
// 处理 item（map[string]*dynamodb.AttributeValue）
id := aws.StringValue(item["id"].S)
name := aws.StringValue(item["name"].S)
age := aws.StringValue(item["age"].N)
location := aws.StringValue(item["location"].S)
log.Printf("ID: %s, Name: %s, Age: %s, Location: %s", id, name, age, location)
}
}? 注意：FilterExpression 在 Scan 中是服务端过滤（即 DynamoDB 返回前剔除不匹配项），但 不会减少读取容量单位（RCU）消耗 —— Scan 仍会读取表中每一条记录（或每个分片中的每条记录），再应用过滤。因此实际 RU 消耗 ≈ 表总数据量 × 项目大小（KB），与过滤结果数量无关。
⚠️ 关键限制与最佳实践
KeyConditionExpression / KeyConditions 是 Query 的强制参数：DynamoDB 明确要求 Query 必须提供分区键条件（EQ 或 BEGINS_WITH 等），否则抛出 ValidationException。这印证了其底层设计原则：Query 是索引驱动的高效查找，不是通用查询引擎。
-
Scan 不可替代 Query 的性能优势：
- ✅ 适用场景：后台批处理、离线报表、小规模表（
- ❌ 禁忌场景：高并发前端接口、实时响应敏感型应用、TB 级大表——会导致延迟飙升、RU 耗尽、成本失控。
-
长期优化建议（架构层面）：
- 若 age > X 是高频查询需求，应创建 全局二级索引（GSI），以 age 为分区键（甚至组合 age + id 为复合主键）；
- 或采用 稀疏索引：仅对满足条件的项写入 GSI（例如 age > 25 时才写入 age-index），节省存储与读取开销；
- 对复杂查询需求，考虑将 DynamoDB 与 OpenSearch、Elasticsearch 或 Aurora（通过 DMS 同步）结合，构建混合查询架构。
✅ 总结
| 操作 | 是否支持 WHERE age > 25 | RU 消耗特点 | 适用规模 |
|---|---|---|---|
| Query | ❌（必须指定 id） | 低（精确索引访问） | 任意（推荐） |
| Scan | ✅（+ FilterExpression） | 高（全表扫描后过滤） | 小型表（ |
切记：DynamoDB 的强大源于其明确的权衡——用“强结构化访问模式”换取极致的可扩展性与低延迟。绕过主键约束的查询，本质是反模式；真正的解决方案永远始于数据建模，而非客户端逻辑补救。
