DynamoDB 不支持同时使用多个全局二级索引（GSI）进行单次查询；正确做法是设计复合主键（如 year#month 或时间戳 SK），配合 KeyConditionExpression 精准定位，再用 FilterExpression 补充非键属性过滤。
dynamodb 不支持同时使用多个全局二级索引（gsi）进行单次查询；正确做法是设计复合主键（如 `year#month` 或时间戳 sk），配合 keyconditionexpression 精准定位，再用 filterexpression 补充非键属性过滤。
在 DynamoDB 中，每个 Query 操作只能指定一个索引（主表或单个 GSI），因此无法像 SQL 的 WHERE year = ? AND month = ? AND state_code = ? 那样，通过多个独立 GSI 并行筛选。试图为 creation_year、creation_month、state_code 各建一个 GSI 并“联合使用”，在 DynamoDB 架构下是不可行的——这会触发多次独立查询，不仅增加延迟与成本，还无法保证原子性与一致性。
✅ 推荐方案：重构主键/索引设计，以支持高选择性查询
1. 方案一：复合 GSI 分区键（推荐用于固定时间粒度查询）
将年份与月份合并为单一字符串作为 GSI 分区键（如 2023#04），避免多索引依赖：
// 创建 GSI：IndexName = "year_month-index"
// Partition key: year_month (e.g., "2023#04")
// Sort key (可选): timestamp 或 log_id，支持范围查询
const command = new QueryCommand({
TableName: "my-table",
IndexName: "year_month-index",
KeyConditionExpression: "#pk = :yearMonth",
ExpressionAttributeNames: { "#pk": "year_month" },
ExpressionAttributeValues: { ":yearMonth": "2023#04" }
});若还需按 state_code 过滤，可在同一查询中添加 FilterExpression（注意：FilterExpression 在 Query 返回结果后执行，不减少读容量消耗）：
// 续上例，追加状态过滤（客户端侧仍需承担扫描开销）
FilterExpression: "#state = :state",
ExpressionAttributeNames: { "#pk": "year_month", "#state": "state_code" },
ExpressionAttributeValues: { ":yearMonth": "2023#04", ":state": "CA" }⚠️ 注意：FilterExpression 不影响 RCUs 计费，仅减少返回数据量；高频、高基数字段（如 state_code）不宜仅靠 Filter，应尽量纳入键设计。
2. 方案二：时间戳排序键（推荐用于精确时间范围 + 多维过滤）
若日志需按毫秒级时间检索（例如排查某次请求链路），建议将 timestamp（ISO 8601 格式）设为 GSI 的排序键，分区键为业务维度（如 log_source 或 service_name）：
// GSI 设计示例：
// Partition key: service_name ("auth-service")
// Sort key: timestamp ("2023-04-01T09:30:45.123Z")
const command = new QueryCommand({
TableName: "my-table",
IndexName: "service-timestamp-index",
KeyConditionExpression: "#pk = :service AND #sk BETWEEN :start AND :end",
ExpressionAttributeNames: {
"#pk": "service_name",
"#sk": "timestamp"
},
ExpressionAttributeValues: {
":service": "auth-service",
":start": "2023-04-01T00:00:00.000Z",
":end": "2023-04-01T23:59:59.999Z"
},
FilterExpression: "#state = :state",
ExpressionAttributeNames: { "#state": "state_code" },
ExpressionAttributeValues: { ":state": "TX" }
});进阶优化：将 state_code 编码进排序键（如 2023-04-01T09:30:45.123Z#TX），即可直接用 BEGINS_WITH 或 BETWEEN 完成键级过滤，彻底规避 FilterExpression 开销。
? 总结与最佳实践
- ❌ 禁止为每个单字段建独立 GSI 并试图“联合查询”；
- ✅ 优先用复合键（year#month、service#state）提升 KeyConditionExpression 能力；
- ✅ 时间敏感场景，用 ISO timestamp 作排序键，支持高效范围查询；
- ✅ 高频过滤字段（如 state_code）若基数适中，可考虑拼接进排序键或设计稀疏索引；
- ✅ 始终评估 FilterExpression 对性能与成本的影响，生产环境建议配合 CloudWatch Metrics 监控 ScannedCount 与 ConsumedCapacity。
