DynamoDB 是無模式的嗎？

是。DynamoDB 是無模式的。除了主索引鍵之外，你在建表時不定義任何屬性或資料型別。每個項目都可以帶著自己那套獨有的屬性，而且它們可以逐項目自由變化——所以你調整資料模型時不必跑模式遷移。

你要預先定義什麼

只有主索引鍵：一個分割區索引鍵（必需）和一個可選的排序索引鍵，外加它們的型別。其他一切都是任意的。你不需要宣告列。

逐項目變化的是什麼

同一張表裡的任意兩個項目可以擁有完全不同的屬性。一個項目裡可能裝著 email 和 status；另一個可能裝著 orderTotal 和一個巢狀的 address 對映。你寫什麼，DynamoDB 就存什麼。

無模式止步於何處

無模式有一條精確的邊界。主索引鍵在每次寫入時都會被校驗；其他什麼都不會。兩個毫無共同屬性的項目可以毫無怨言地進同一張表：

await client.send(
  new PutItemCommand({
    TableName: 'people',
    Item: {pk: {S: 'USER#1'}, email: {S: 'a@b.c'}, status: {S: 'active'}}
  })
);
await client.send(
  new PutItemCommand({
    TableName: 'people',
    Item: {
      pk: {S: 'ORDER#1'},
      orderTotal: {N: '42.5'},
      address: {M: {city: {S: 'Madrid'}}},
      tags: {SS: ['a', 'b']}
    }
  })
);

兩次都成功。現在把同一個分割區索引鍵寫成數字而不是字串：

ValidationException: One or more parameter values were invalid: Type mismatch for key
HTTP 400

再完全省略 pk：

ValidationException: One of the required keys was not given a value
HTTP 400

這兩次拒絕就是全部的模式。鍵屬性必須存在，而且必須與 AttributeDefinitions 裡宣告的型別一致。除此之外的一切都會被照單接收。

打字錯誤也照樣透過。寫入時不會有任何東西告訴你 staus 本該是 status。

它為什麼有用

無需遷移——隨時增刪屬性。
混合實體——多種實體型別可以共用一張表（單表設計）。
可演進——模型隨需求一起變。

代價是：任何你所依賴的形狀，都由你的應用而不是資料庫來保證。

深入瞭解

參見單表設計和用於混合項目的 type 屬性模式。下載 DynoTable 來檢查真實的項目形狀。

每項 400 KB — 屬性名稱和值均計入上限。
32 個巢狀級別，用於值內的對映和列表。
單個屬性名稱的最大長度為 65,535 位元組。
每次 BatchWriteItem 呼叫最多 25 項。

您可以在一項上放置 status 字串，並在下一項上省略它，但不能在任一項中儲存 500 KB 的 blob。在寫入之前使用 item size calculator 來測量有效負載，並在一個表中混合實體型別時讀取 single-table design。

在 DynoTable 中： 在任何表上開啟設定並為其建立索引。推斷的模式是根據取樣項構建的，並誠實地標記 - 它顯示您所編寫的內容，而不是您宣告的內容。本地索引如何取樣和重新整理請參見表總覽與索引。

深入了解

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

2026-07-28 針對 DynamoDB Local 3.3.0，用 Node v24.18.0 上的 @aws-sdk/client-dynamodb 3.1095.0 復現。兩條 ValidationException 訊息都是引擎原樣輸出。

深入了解

根據上面連結的官方AWS文件上次驗證時間為 2026 年 7 月 13 日。

於 2026 年 7 月 28 日在 Node v24.18.0 上透過 @aws-sdk/client-dynamodb 3.1095.0 針對 DynamoDB Local 3.3.0 複製。兩條ValidationException訊息都是逐字引擎輸出。