DynamoDB 的 Limit 参数限制的是扫描/评估的项目数（预过滤），而非最终返回的匹配项数量；若需精确控制返回行数，必须结合分页逻辑与客户端侧过滤，或通过索引优化查询结构。
dynamodb 的 `limit` 参数限制的是扫描/评估的项目数（预过滤），而非最终返回的匹配项数量；若需精确控制返回行数，必须结合分页逻辑与客户端侧过滤，或通过索引优化查询结构。
在 DynamoDB 中使用 PartiQL（如 SELECT * FROM transactions WHERE completed = 0）时，很多人期望 Limit => 1 能像传统 SQL 那样「严格返回最多 1 条匹配结果」。但实际行为截然不同：Limit 控制的是 DynamoDB 在单次请求中最多「读取并评估」的项目数量，而非应用 WHERE 过滤后返回的条目数。
例如，假设表中有 10,000 条 completed = 0 的记录，但它们分散在大量数据中（无高效索引），而你设置 'Limit' => 1：
$result = $client->executeStatement([
'Limit' => 1,
'Statement' => "SELECT * FROM transactions WHERE completed = 0",
]);DynamoDB 会：
- 从物理存储中顺序读取（或按分区键扫描）最多 1 个项目；
- 对该项目执行 WHERE completed = 0 判断；
- 若不匹配 → 返回空结果集（即使后续有匹配项）；
- 若匹配 → 返回该 1 条，且 不会继续查找。
⚠️ 关键点：Limit 是「评估上限」，不是「结果上限」。它无法保证返回 至少 N 条 或 恰好 N 条 匹配数据。
✅ 正确实现「获取前 N 条匹配结果」的推荐方案
方案 1：使用全局二级索引（GSI）+ Query（最高效）
若高频查询 completed = 0，应为 completed 属性创建 GSI（如 completed-index），并将 completed 设为分区键：
-- 创建 GSI 后，改用 Query（非 PartiQL）： -- KeyConditionExpression: #completed = :val -- IndexName: "completed-index"
此时 Limit 行为符合直觉：
✅ Limit => 1 将返回 最多 1 条 completed = 0 的匹配项（因 GSI 已将匹配数据物理聚集）；
✅ 不会浪费读容量在无关项目上；
✅ 响应快、成本低。
方案 2：PartiQL 分页 + 客户端累积（通用但需注意）
当无法建索引时，需主动处理分页，并在客户端收集足够结果：
$targetCount = 1;
$collected = [];
$nextToken = null;
do {
$params = [
'Statement' => "SELECT * FROM transactions WHERE completed = 0",
'Limit' => 100, // 每次评估最多 100 项，平衡延迟与吞吐
];
if ($nextToken) {
$params['NextToken'] = $nextToken;
}
$response = $client->executeStatement($params);
$items = $response['Items'] ?? [];
// 客户端过滤（此处 WHERE 已由服务端执行，但 Limit 是预评估，故 items 数量 ≤ Limit）
foreach ($items as $item) {
$collected[] = $item;
if (count($collected) >= $targetCount) break 2; // 提前退出双层循环
}
$nextToken = $response['NextToken'] ?? null;
} while ($nextToken && count($collected) < $targetCount);
// $collected 现在包含严格不超过 $targetCount 条匹配结果? 注意：executeStatement 响应中若含 NextToken（而非 LastEvaluatedKey），表明需用 NextToken 继续分页；这是 PartiQL API 的统一分页机制。
方案 3：强一致性 + 估算 + 重试（慎用）
仅适用于极低数据量场景：先用小 Limit 试探，若结果为空且怀疑漏匹配，增大 Limit 重试。但不推荐——违背 DynamoDB 的可扩展设计原则，易引发高延迟与突发读消耗。
? 总结与最佳实践
- ❌ 不要依赖 Limit 实现 SQL 式的「结果数量硬限制」；
- ✅ 优先为常用查询条件（如 completed）建立 GSI，转用 Query 操作；
- ✅ 使用 PartiQL 时，将 Limit 视为「单次请求资源预算」，配合 NextToken 分页 + 客户端逻辑裁剪；
- ✅ 始终检查响应中的 NextToken 字段，避免遗漏数据；
- ✅ 对高并发低延迟场景，考虑启用 DAX 加速读取，但注意 DAX 不支持 PartiQL（需改用 Query/GetItem）。
DynamoDB 的设计哲学是「可控成本、可预测性能」——它拒绝为模糊查询承担全表扫描风险。理解 Limit 的语义边界，是写出高效、可伸缩 NoSQL 查询的关键一步。
