本文是 Cloud Spanner overview 的 implementation-layer deep article。Overview 已說明 Spanner 在全球 OLTP 譜系的定位、本文聚焦 schema migration without downtime + interleaved tables — Spanner 兩個跟傳統 SQL 差異最大的 schema 機制。

問題情境：DDL 不停機跟 parent-child 物理 layout 的兩個疑問

傳統 PostgreSQL / MySQL DDL 拿 ACCESS EXCLUSIVE / metadata lock、線上跑 ALTER TABLE 動輒鎖表幾分鐘、大型 schema change 要 pt-osc / gh-ost / pg_repack 等外掛工具。Spanner 宣稱「schema change 不停機」、但團隊不知道實際機制跟邊界。讀者徵兆通常從這幾個地方浮現：「Spanner ALTER 真的不卡寫入嗎」「INDEX backfill 跑了 12 小時是正常嗎」「parent-child 的 INTERLEAVE IN PARENT 是什麼黑魔法」「ON DELETE CASCADE 在 interleaved table 為什麼是 storage-level 而不是 application-level」。

真實壓力：multi-tenant SaaS 要對 100 億 row 的 orders 表加 column + 加 index、不能停機、不能讓 p99 write latency 超過 SLA。團隊以為「Spanner schema change 不停機」等同於「DDL 瞬間完成」、實際 ALTER 是 long-running operation、index backfill 在大表上跑數小時到數天、capacity 規劃要把 backfill 期間的 CPU 升幅算進去。

Case anchor：缺案例。9.C10 是 Google internal dogfood case、未展開 schema migration 細節、且 9.C10 不是 customer-facing capacity reference。本文用通用 pattern + 官方文件 + 反向回 PostgreSQL Online Schema Change 對照、待後續 customer case audit 補強。

核心機制：DDL 是 long-running、TrueTime 對齊 schema version

Schema change 的 lifecycle

Spanner DDL 不是同步 ALTER、是 long-running operation。TrueTime 給每次 schema change 分配一個 version timestamp、所有 read / write 用各自 transaction timestamp 對應「當下看到哪個 schema version」。讀者要理解的核心是：DDL 不是「鎖表→改→解鎖」、是「廣播新 schema version、讓現有 transaction 用舊 schema、新 transaction 用新 schema、背景 backfill 物理資料」。

 1時間軸：
 2
 3T0 (DDL 開始)
 4     |
 5     | ──── 舊 schema 仍可用、新 schema metadata 廣播 ────
 6     |
 7T1 (metadata 完成)
 8     |
 9     | ──── 新 transaction 用新 schema、舊 transaction 完成自己 ────
10     | ──── backfill 開始（背景）────
11     |
12T2 (backfill 完成)
13     |
14     | ──── 新 schema fully serve ────

DDL 本身瞬間完成的部分是 metadata 廣播（毫秒到秒級）、慢的部分是 backfill（依資料量、可能數小時到數天）。讀者常見誤解是把 metadata 完成當「DDL 完成」、實際 query 還沒走新 index 因為 backfill 沒跑完。

不停機的關鍵：不同 DDL 的兩階段行為

讀者要記的是：index backfill 完成前、query 該 index 會 fallback 到 table scan、用 EXPLAIN 確認 query plan 走新 index 才算真正完成。沒做這層驗證、團隊會以為 CREATE INDEX 已經成功、實際 p99 query latency 還在表掃描的數量級。

Interleaved table 的設計

Interleaved Table 把 parent table（如 Customer）跟 child table（如 Order）的 row 在 storage 層 物理上交錯儲存 — child row 跟對應 parent row 在同一個 split。不是純 foreign key、是 storage layout：

 1傳統 PostgreSQL FK 設計（兩張獨立表）：
 2Customer table:  [c1, c2, c3, ...]  → 一張表、一段 storage range
 3Order table:     [o1, o2, o3, ...]  → 另一張表、另一段 storage range
 4FK 由 planner 在 JOIN 時拼接、可能跨 page / 跨 segment
 5
 6Spanner Interleaved 設計（物理交錯）：
 7Storage layout: [c1, c1.o1, c1.o2, c2, c2.o1, c2.o2, c2.o3, c3, ...]
 8                 |____________________|  |________________|
 9                  c1 + 其 child           c2 + 其 child
10                  在同一個 split          在同一個 split

Interleaved 的效果：parent + child JOIN 在同一個 Range Sharding split 完成、不跨 split = 不跨 Paxos group = 低延遲 transaction。這條設計把「FK 是 logical constraint」翻成「parent-child access pattern 是 physical co-location」、對 access pattern 固定的 workload（customer → orders、user → posts、tenant → records）是巨大 latency benefit。

Interleaved 的硬限

最後一條是讀者最容易踩的雷 — 一開始沒設 interleaved、後悔時要 export-import 100 億 row、是大工程、不是 ALTER。Schema 設計階段要先 audit access pattern、決定哪些 parent-child 該 interleave。

跟通用 FK 概念的差異

PostgreSQL FK 是 logical constraint、JOIN 由 planner 處理；Spanner interleaved 是 physical layout、JOIN cost 跟 single-table access 接近。對應 transaction-boundary 卡 — interleaved 讓 transaction boundary 跟 storage boundary 對齊、跨 split transaction 變少、commit wait + Paxos round-trip 也省。

操作流程：DDL 跟 interleaved table 的具體步驟

加 column

1ALTER TABLE Orders ADD COLUMN tax_amount FLOAT64;

執行後拿 long-running operation id、用 gcloud spanner operations list 觀察狀態：

1gcloud spanner operations list --instance=prod --database=app
2gcloud spanner operations describe projects/.../operations/<op-id>

驗證點：operation 顯示 done: true 後、跑 SELECT tax_amount FROM Orders LIMIT 1 確認 column 可查。

加 index

1CREATE INDEX OrdersByCustomer ON Orders(customer_id);

拿 operation id → 用 Monitoring metric spanner.googleapis.com/instance/indexes/backfill_progress（或對應的最新 metric、查官方文件）追蹤進度。Backfill 完成前 query 不會走新 index、要用 EXPLAIN 確認：

1EXPLAIN SELECT * FROM Orders WHERE customer_id = 'c123';
2-- 應看到 plan 用 OrdersByCustomer index、不是 table scan

創建 interleaved table

1CREATE TABLE `Order` (
2    customer_id INT64 NOT NULL,
3    order_id INT64 NOT NULL,
4    amount FLOAT64,
5    created_at TIMESTAMP,
6) PRIMARY KEY (customer_id, order_id),
7  INTERLEAVE IN PARENT Customer ON DELETE CASCADE;

關鍵約束：

• child PK (customer_id, order_id) 第一段是 parent PK
• ON DELETE CASCADE 是 storage-level — 刪 parent row 自動刪 child row、Spanner 內部處理、不是 trigger

從 non-interleaved 改成 interleaved

無法直接 ALTER、要走 export-recreate-import：

1. 用 Dataflow / gcloud spanner databases export 把舊表 export 到 GCS
2. 建新表（interleaved schema）
3. 用 Dataflow / gcloud spanner databases import 把資料倒回
4. 應用層 cutover（feature flag / dual write）

這個流程是 mini-migration、要走完整 migration playbook 的 phase plan。Schema 設計階段就決定好 interleave、避免後悔成本。

Rollback boundary

DDL 完成前可 gcloud spanner operations cancel 取消；完成後加 index 要 DROP、加 column 要 DROP COLUMN（同樣是 long-running）。讀者要先確認自己在 DDL 哪個階段、cancel 跟 reverse DDL 是兩條不同路徑。

失敗模式：5 個 production 踩雷

Backfill 時間沒估、event window 撞牆

100 億 row 加 index、預期 1 小時、實際 12 小時 — 沒先用 cost 估 + 沒監控進度 metric。事故場景：團隊在 black friday 前一週開 CREATE INDEX、以為週末跑完、實際週末仍在 backfill、event 期間 CPU 升、query latency 退化。

修法：

• DDL 前用小表 benchmark backfill 速度（rows/sec）、推估大表時間
• DDL 期間監控 instance/cpu/smoothed_utilization、若 > 80% 暫停或降流量
• 大 DDL 排在 capacity headroom 充足的時段、避開 event window

Interleaved table 一開始沒設、後悔時要 recreate

100 億 row export-import + cutover 是大工程、不是 ALTER。事故場景：團隊一開始把 Customer / Order 設成獨立表、上線一年後發現 customer → orders access pattern 是 99% 的 query、JOIN 跨 split 付 commit wait + Paxos cost、想改 interleaved、發現要 mini-migration。

修法：

• Schema 設計階段就 audit access pattern、決定哪些 parent-child 該 interleave
• 寫 ADR 把 interleave 決策跟業務 access pattern 綁定、避免後悔成本

把 interleaved 跟 FK 混為一談

interleaved 的 ON DELETE CASCADE 是 storage-level、刪 parent 自動刪 child；非 interleaved FK 要 application 或 trigger 處理。事故場景：團隊以為「我加了 FK 就會 CASCADE」、實際非 interleaved table 只是 constraint check、刪 parent 時 child orphan、對帳爆炸。

修法：

• Schema 設計時明確分類：interleaved（storage-level CASCADE）vs FK constraint（只檢查、不 CASCADE）
• 非 interleaved 的 parent-child 刪除邏輯放應用層、寫入對帳測試

加 NOT NULL 一步到位

直接 ALTER ADD COLUMN x INT64 NOT NULL 會失敗、必須兩階段。事故場景：開發環境 schema 是新建空表、ADD COLUMN NOT NULL OK；production 表有資料、ADD 失敗、團隊以為 Spanner 不支援、回退。

修法：

1-- Phase 1: ADD with default
2ALTER TABLE Orders ADD COLUMN tax_amount FLOAT64 DEFAULT 0;
3-- 等 backfill 完成
4
5-- Phase 2: ADD CONSTRAINT
6ALTER TABLE Orders ALTER COLUMN tax_amount SET NOT NULL;

Schema change 期間舊 client 還在用舊 schema

TrueTime 保證 read 看到自己 timestamp 對應的 schema version、但 client SDK cache schema 過期會 retry — 沒處理會看到 transient error。事故場景：DDL 完成後、舊 client session 看到 transient FAILED_PRECONDITION、團隊以為 DDL 失敗、回退。

修法：

• 應用層處理 transient retry（指數退避）
• DDL 完成後重新 deploy app instance、避免長期 stale schema cache

容量與觀測：Backfill 是 CPU + I/O 的額外負載

必看 metric：

1spanner.googleapis.com/instance/cpu/smoothed_utilization
2   → backfill 期間 CPU 升幅、判讀是否撞 headroom
3api/api_request_count for ExecuteSql
4   → application traffic 是否受 backfill 影響
5long-running operation API progress
6   → DDL 自身進度（不是 query 進度）

Backfill 期間的 capacity impact：DDL 跑在 background priority、但仍佔 CPU、需要在 instance 有足夠 headroom（建議 < 65% CPU baseline 才開大 backfill）。capacity 規劃要把 schema migration 列入 buffer、回 9.6 容量規劃模型。

Observability evidence：backfill 開始 timestamp、operation id、predicted duration、實際 duration、CPU peak — 全進 incident decision log、回 4.20 Observability Evidence Package。

監控盲點：DDL operation 失敗 silent fail 在 gcloud operations describe 才能看到、Cloud Monitoring 沒有直接 alert。團隊要寫自己的 polling script、operation 失敗時主動 alert、不靠 Cloud Monitoring default。

邊界與整合：何時不用 interleaved、怎麼跟 PG 對照

何時不用 interleaved

• 小 table（< 1M row、單機可放）：不需要 interleave、用 standard FK 就好
• 過度 interleave 7 層：把 split 變窄、反而 hot、得不償失
• access pattern 不是 parent-child JOIN：interleave 沒 benefit、純粹給 schema 加複雜度

跟 PostgreSQL 的對照

PostgreSQL Online Schema Change 用 pg_repack / pt-osc workflow 模擬「不停機」 — 實際是用 trigger + 影子表 + cutover 把 lock 時間壓到秒級、不是真正瞬間。Spanner 是原生支援 DDL long-running operation、不需要外掛工具、但 backfill 時間在大表上仍長、跟 pg_repack 在大表上的執行時間量級接近。

差異點：

讀者選 Spanner 不是為了「DDL 更快」、是為了「不依賴外掛 + 多版本並存」。實際在大表上的耗時兩邊差不多。

Sibling deep articles

• truetime-api-depth：schema version 也是 TrueTime timestamp、跟 transaction timestamp 同層機制
• migrate-from-cloud-sql-pg：target schema 設計含 interleaved、Phase 1 必讀本文
• consistency-models-comparison：schema change 期間多版本並存的一致性保證

跟 1.x 章節

Schema Design — interleaved 是 schema 設計的物理層決策、不是純 logical design。對照 schema-migration-rollout-evidence 看 schema rollout 的 evidence 收集模式。

Anti-recommendation

讀者讀完本文應該能判斷：interleaved 不是「強制使用」的 feature、是「access pattern 固定時的 latency benefit」。小規模 OLTP、access pattern 不確定的 workload、用 standard PostgreSQL FK 就好、為 interleaved 付 schema 後悔成本的判準很高。

本文的判讀錨點是：MDL 事故通常來自 DDL 排隊在長交易後面，並把後續 query 一起擋住。解法要同時處理 long transaction、DDL window、OSC 工具與 observability。

Lock Lifecycle

Lock lifecycle 的核心責任是建立 MDL 心智模型。

MDL 的風險在於排隊。當 ALTER TABLE 等待 long transaction 時，後續新的 query 可能排在 DDL 後面，讓原本小變更變成服務不可用。

Detection

Detection 的核心責任是快速找出誰持鎖、誰等待。

1SELECT *
2FROM performance_schema.metadata_locks
3WHERE OBJECT_SCHEMA = 'appdb'
4ORDER BY OBJECT_NAME, LOCK_STATUS;

搭配 processlist：

1SHOW FULL PROCESSLIST;

Production dashboard 應監控 running DDL、metadata lock wait、long transaction age、threads running、blocked query count 與 replication lag。

DDL Risk Review

DDL risk review 的核心責任是在變更前預測 MDL 風險。

DDL review 要列出 algorithm、lock mode、預估時間、rollback、kill blocker policy 與 replication impact。

Incident Runbook

Incident runbook 的核心責任是把 MDL 事故分流。

Kill session 是高風險操作。決策要記錄 transaction owner、已執行時間、可能 rollback 成本與業務影響。

OSC Interaction

OSC interaction 的核心責任是說明 gh-ost / pt-online-schema-change 仍需要 MDL 管理。Ghost table 工具把大部分 copy 與 backfill 移到旁路，但最後 cutover / rename 仍需要短暫 metadata lock。

OSC runbook 要在 cutover 前檢查 long transaction。若 blocker 存在，先延後 cutover，而非硬切。

Prevention

Prevention 的核心責任是讓 MDL 事故在 release 前被擋下。

1. Long transaction alert。
2. DDL dry run 與 algorithm / lock mode 記錄。
3. Migration window 與 kill blocker policy。
4. OSC cutover pre-check。
5. Application transaction timeout。
6. Read-only replica 上先測 schema change。

MDL 是 MySQL schema governance 的核心議題。每個 production DDL 都要有 metadata lock plan。

下一步路由

Metadata lock deep dive 完成後，schema change 工具讀 Online Schema Change Tools；lock 行為讀 Lock Contention；操作演練讀 Online Schema Change Lab。