Consistent reads are not supported on global secondary indexes

TL;DR — 你在一個針對全域次要索引的 Query 或 Scan 上設定了 ConsistentRead: true。GSI 從基礎表非同步複製，只提供最終一致讀取——這個標誌是一個硬性錯誤，而非偏好設定。去掉該標誌，或者如果你確實需要寫後讀一致性，就讀取基礎表（或者把該鍵設計進一個 LSI）。

這是什麼意思

ValidationException: Consistent reads are not supported on global secondary indexes

一個 GSI 在物理上是它自己的索引結構，有自己的分割槽和容量；DynamoDB 會把基礎表的寫入非同步地傳播進去。因為你剛寫入的項目可能還沒到達索引，DynamoDB 無法對它兌現一個強一致讀取——因此 ConsistentRead: true 與 GSI 的 IndexName 組合會被直接拒絕。AWS 文件說得很明確：用 ConsistentRead 設為 true 查詢一個 GSI，你會收到 ValidationException。

本地次要索引則不同：一個 LSI 與基礎表共享其分割槽，因此那裡支援 ConsistentRead: true。

為什麼會發生

該標誌被全域性設定——一個共享的查詢輔助工具或用戶端封裝為每次讀取預設設定 ConsistentRead: true，而某條呼叫路徑新增了一個指向 GSI 的 IndexName。
一個 LSI 變成了 GSI——為本地索引（那裡該標誌合法）編寫的程式碼被指向了一個全域性索引。
複製貼上的基礎表查詢——一個在表上合法地使用了強一致的查詢，被加上 IndexName 後重用了。

如何修正

從 GSI 讀取中移除 ConsistentRead（或把它設為 false——預設值）：

await client.send(
  new QueryCommand({
    TableName: 'Orders',
    IndexName: 'status-index',
    KeyConditionExpression: '#s = :open',
    // ConsistentRead: true  ← delete this line for a GSI
    ExpressionAttributeNames: {'#s': 'status'},
    ExpressionAttributeValues: {':open': {S: 'OPEN'}}
  })
);

需要寫後讀？ 用 ConsistentRead: true 查詢基礎表——只要你要查詢的鍵是表自己的分割區索引鍵，就可以做到。
相同的分割區索引鍵，不同的排序？ 把它建模為一個 LSI（在表建立時建立），它支援一致性讀取。
或者在應用中吸收這個延遲——GSI 傳播通常很快；對於 UI 流程，返回你已經擁有的剛寫入的資料勝過重新讀取索引。

DynoTable 桌面應用會顯示每張表的索引並讓你直接查詢它們——而且因為它知道哪個索引是全域性的、哪個是本地的，這類錯誤壓根不會出現。

在 DynoTable 中核對

DynoTable 知道哪些索引是 GSI 與 LSI — GSI 查詢從不傳送 ConsistentRead: true。使用 ⌘K 開啟表，從下拉選單中選擇一個索引，然後執行不帶標誌的查詢。當你需要先寫後讀時，請改為查詢基表 - Query Builder 為每個目標生成正確的引數。使用 ⌘P 切換設定檔案；參見連線 AWS和安裝。

來源

Query — Amazon DynamoDB API Reference（2026-07-13 驗證）
Using Global Secondary Indexes in DynamoDB（2026-07-13 驗證）

參考資料

最後核實於 2026-07-13，依據上方連結的 AWS 官方文件。