本頁面由 Cloud Translation API 翻譯而成。

主索引鍵遷移作業總覽

本頁說明 Spanner 如何搭配主鍵運作，並針對下列用途提供主鍵遷移策略：

主鍵的常用方法是使用代理鍵，例如自動遞增的數字。這類主鍵可讓您靈活調整現在和日後的鍵，即使業務邏輯有所變動也沒問題。在單一執行個體資料庫中，序號鍵在資料量偏低的情況下，效能表現良好。不過，在分散式系統中，連續索引鍵的擴充性不佳。

Spanner 中的連續主鍵

在 Spanner 中，每個資料表都有一個主鍵，由該資料表的一或多個資料欄組成。您的資料表的主鍵將唯一識別資料表中的每一列，Spanner 會使用主索引鍵，在 Spanner 執行個體的運算節點中，將資料列群組 (稱為分割) 進行分散。這稱為範圍分割，可讓 Spanner 平行處理查詢並擴充。

如果資料列的主鍵值相近 (例如單調遞增的自動遞增鍵)，就可能會落在相同的分割區。這麼做可以建立熱點，讓分割作業可以使用所有可用的運算和記憶體資源。資源使用率不均可能會導致延遲時間增加，進而導致交易逾時和中斷。

為充分利用 Spanner 的擴充性並避免熱點，Spanner 提供內建解決方案，做為自動遞增主鍵的替代方案。

在 Spanner 中，我們建議您使用通用唯一識別碼第 4 版 (UUIDv4) 值做為主鍵的預設值。UUID 是 128 位元 ID，使用 122 位元隨機資料。UUIDv4 值的值範圍非常廣泛，且無論產生位置為何，都會產生唯一的值。因此，這些鍵很適合用於 Spanner 中非熱點的主鍵。

您可能會想要使用整數主鍵，因為這類主鍵所需的空間較少，且可減少應用程式變更作業的複雜度。您可以使用正向位元反轉序列，產生不重複的主鍵值，並將這些值均勻分散在正向 64 位元整數空間中。

如要進一步瞭解如何選擇主鍵以避免資源使用率不均，請參閱「結構定義設計最佳做法」。

視應用程式用途和需求而定，您可以部署主鍵遷移策略。每個遷移策略都會：

假設您要從使用 UUID 主鍵的資料庫遷移至 Spanner。在來源資料庫中將現有的 UUID 鍵設為字串，然後原封不動地匯入 Spanner。無論 UUID 值 (尤其是 v4) 產生位置為何，都會是唯一的。

您可以使用 Spanner 上的 GENERATE_UUID() 函式 (GoogleSQL、PostgreSQL) 來遷移 UUID 鍵資料庫。

如需 UUID 索引鍵資料庫遷移操作說明，請參閱「遷移 UUID 索引鍵資料欄」。

請考慮從使用序列單調鍵的單一執行個體資料庫進行遷移，例如 MySQL 中的 AUTO_INCREMENT、PostgreSQL 中的 SERIAL，或是 SQL Server 或 Oracle 中的標準 IDENTITY 類型。

設定 Spanner SEQUENCE 物件，以便略過現有鍵範圍中的值，並產生新的位元反轉鍵。Spanner SEQUENCE 物件產生的位元反轉鍵一律大於零，並且均勻分布在正 64 位元整數空間中。

如要瞭解如何遷移含有序號鍵的資料庫，請參閱「遷移自動產生的序號主鍵」一文。

假設您要從使用序列單調鍵的單一執行個體資料庫遷移至 Spanner，並支援複製情況，例如，您想要在資料庫系統之間進行即時切換。

設定 Spanner SEQUENCE 物件，以便略過來源資料庫中現有鍵的整個值範圍，並在 Spanner 上產生新的位元反轉鍵。由 Spanner SEQUENCE 物件產生的位元反轉鍵一律大於零，但沒有排序。

如需有關遷移支援即時切換的資料庫操作說明，請參閱「使用 Spanner 和來源資料庫」。

假設您要從使用遞增單調鍵的資料庫進行遷移，且應用程式邏輯會依據主鍵順序判斷最近的資料，或將新建立的資料排序。

建立複合鍵，將均勻分布的值 (例如區塊 ID 或雜湊) 做為第一個元件，將序號做為第二個元件。這樣一來，系統就能保留有序的鍵值，而不必造成大規模的熱點。

如要瞭解如何遷移含有應用程式邏輯依附元件的順序鍵資料庫，請參閱「遷移您自己的主鍵」一文。