某應用程式將資料儲存在 DynamoDB 中。有些查詢因為篩選的屬性既不是資料表的 partition key 也不是 sort key，導致查詢速度緩慢。資料集將會大幅成長。要改善該屬性的查詢效能，應該做什麼改變？

當查詢的屬性既非 partition key 也非 sort key 時，DynamoDB 必須執行全表掃描，這在資料集龐大時效率極低。建立一個 Global Secondary Index (GSI) 允許您為不同的查詢模式定義替代的 partition key 和 sort key。將被查詢的屬性設為 GSI 的 partition key，可以讓 DynamoDB 針對該屬性進行高效的索引查找，大幅提升查詢速度。 其他選項的解釋： 透過設定更高的 Limit 來增加請求頁面大小，並讓應用程式重試超出佈建輸送量的請求：這只會增加每次請求返回的項目數量，並不會解決底層的查詢效率問題，反而可能因為重試而增加延遲。 透過發出帶有多個區段的 segmented scan 請求來使用平行掃描：平行掃描雖然可以加速全表掃描，但它仍然是掃描操作，效率遠不如索引查找，且會消耗大量讀取容量。 啟用讀取容量自動擴展並提高資料表的讀取容量單位 (RCU) 上限：增加 RCU 只能解決因容量不足導致的節流問題，無法改善查詢本身的效率。如果查詢效率低下，即使有足夠的 RCU，查詢仍然會很慢且成本高昂。