觀點 · 資訊分享

Cloud Spanner 放寬寫入上限：8 萬次變更改成每條 DML 語句各算，同一交易可連跑多條大型寫入

Google Cloud 在 8 月 11 日更新 Spanner：DML 語句的 80,000 次變更上限（含索引）從整個交易累計改成每條語句各自計算；Mutation API 與 100 MiB 提交上限不變。

一句話看懂：Google Cloud Spanner 把「單一交易最多 8 萬次變更」的限制，改成「每一條 DML 語句各自最多 8 萬次」，一個交易裡可以連續跑好幾條大型寫入語句了。

Spanner 放寬 DML 變更上限資訊圖卡：8 萬次變更的上限，改成每條 DML 語句各自計算

先用白話講：這個限制在管什麼？

想像你去銀行辦一個「大型業務」，櫃台規定：一張申請單最多處理 8 萬筆資料的修改（包含相關的索引更新）。以前不管你這張單子裡寫幾個步驟，全部加起來不能超過 8 萬筆，不然整張退件。

新規則改成：單子裡的每個步驟各自不能超過 8 萬筆，步驟之間不用加總。所以你可以一張單子寫好幾個大步驟，只要每一步都在額度內就行。

依 Google Cloud 的 Spanner 更新日誌，8 月 11 日起：

對 DML 語句（INSERT、UPDATE、DELETE 這類改資料的 SQL），Spanner 把 80,000 次變更（mutation，含索引）的上限，從「整個交易累計」改成「每一條語句」
因此一個交易可以執行多條 DML 語句，即使它們加起來超過 80,000，只要每一條都沒超過就可以
如果是用 Mutation API（不經 SQL、直接送變更的介面），80,000 的限制仍然是套用在同一次提交的所有變更
所有交易仍然受 100 MiB 的提交大小上限限制

以下是舉例（非官方數字）：假設一個交易要連續做三次大量更新，每次影響 4 萬次變更。

這類「放寬限制」的更新，看似小，卻很實用：很多系統在做資料整理、欄位回填的時候，最煩的就是被某個神秘的上限卡住，只好寫一堆分批程式。把限制從「整個交易」改成「每條語句」，對這類維運工作很友善。

不過我會建議別因為限制放寬就把交易越做越大。大交易一旦失敗，要重來的成本也大；跟線上流量同時跑時，還可能拖慢別的請求。比較穩的做法依然是分批、每批設合理的大小，並且在離峰時間做。放寬的是上限，不是建議值。

Mutation（變更）是什麼？

Spanner 用來計算一次寫入影響多少資料的單位，官方說明這個計數包含索引。所以更新一筆有多個索引的資料，變更數會比單看欄位多。

我現在可以用單一 DML 語句更新 20 萬筆嗎？

不行。上限改成「每條語句」之後，單一語句仍然不能超過 80,000 次變更；放寬的是同一個交易裡多條語句不用加總。

用 Mutation API 的人有影響嗎？

沒有放寬。依更新日誌，Mutation API 的 80,000 上限仍套用在同一次提交的所有變更。

作者

接案做系統開發、網站與主機託管。觀點裡的文章都是我自己寫的,寫的是做專案時第一手遇到的事。