DynamoDB 查詢建構器
組合整個 Query 或 Scan 請求 — 表格、Index、鍵條件、Filter、投影、Limit、排序方向、一致性讀取與分頁 — 並複製可執行的 AWS SDK v3、CLI 或 boto3 程式，或 PartiQL 陳述式。
從存取模式到可執行的請求
表達式很少是全部的工作。正式環境的 Query 還要決定讀取哪個 Index、每次請求評估多少項目、sort key 朝哪個方向掃描、讀取是否必須強一致，以及回應帶著 LastEvaluatedKey 回來時該怎麼辦。這些請求層級參數存在於表達式字串之外 — 而複製貼上的程式碼片段通常就在這裡出錯。
這個建構器把請求當作工作單位。你在與我們的表達式建構器相同、具型別且對保留字安全的模型上組合鍵條件、Filter 與投影，並在旁邊設定請求選項。輸出不是片段，而是可以執行的程式 — import、用戶端初始化、呼叫本身，以及在啟用「取得所有頁面」時，把每一頁結果都讀完的 ExclusiveStartKey 迴圈。
產生的程式碼對每個目標都保持誠實。AWS CLI 會自行分頁，所以它的 Limit 變成 --page-size，單次請求執行則加上 --no-paginate；PartiQL 婉拒屬於 ExecuteStatement API 而非陳述式本身的參數；遞減的 Query 在可表達時會變成對 sort key 的 ORDER BY。
只需要表達式本身 — 六種操作中任一種的條件、Filter 或更新表達式及其佔位符對應表？ DynamoDB 表達式建構器正是為此而打造。 還在兩種讀取操作之間做決定？ Query 與 Scan 的比較 拆解了各自適用的時機。
常見問題
這與 DynamoDB 表達式建構器有什麼不同？
兩者刻意分工。表達式建構器的主題是表達式語法 — 涵蓋全部六種操作的鍵條件、Filter、更新與條件表達式，以及它們的 ExpressionAttributeNames/Values 對應表 — 並且只輸出指令本身。查詢建構器的主題是完整的 Query 或 Scan 請求：表格與 Index、鍵條件、Filter、投影，再加上表達式工具沒有提供的請求層級參數（Limit、排序方向、ConsistentRead、ExclusiveStartKey），並輸出一個含用戶端初始化與可選分頁迴圈的可執行程式。
在 Query 或 Scan 中，Limit 究竟限制什麼？
Limit 限制的是 DynamoDB 每次請求評估的項目數，而不是你拿回的符合項目數。Filter 在讀取之後才執行，所以帶著 Limit 25 與 FilterExpression 的 Query 可能回傳不到 25 個項目 — 甚至一個也沒有 — 卻仍消耗其評估內容的全部讀取容量，分頁則從 LastEvaluatedKey 繼續。在會自動分頁的 AWS CLI 中，同一個參數以 --page-size 設定。
DynamoDB 分頁（LastEvaluatedKey）如何運作？
仍有更多資料的 Query 或 Scan 回應會包含 LastEvaluatedKey — 也就是最後讀取項目的主鍵。你在下一次請求中將它作為 ExclusiveStartKey 傳回，反覆進行直到收到不含它的回應。開啟「取得所有頁面」後，產生的 SDK v3 與 boto3 程式正包含這個迴圈；除非你傳入 --no-paginate，AWS CLI 會自行逐頁讀取。
什麼時候可以使用強一致讀取？
ConsistentRead 適用於基礎表格與 local secondary index，但不適用於 global secondary index — 對 GSI 發出且設定了 ConsistentRead 的 Query 會被拒絕。強一致讀取消耗的讀取容量也是最終一致讀取的兩倍。它是 API 參數，而非 PartiQL 陳述式文字的一部分，這也是 PartiQL 分頁誠實婉拒它的原因。
我在這裡輸入的內容會被上傳到任何地方嗎？
不會。這是靜態頁面：請求的組合與程式碼的產生完全在你的瀏覽器中完成，表格名稱、鍵值與 Filter 永遠不會到達伺服器。「複製連結」會把整個請求打包進 URL — 分享那個連結是你輸入的內容離開頁面的唯一途徑，而這由你決定。