觀點 · 資訊分享

Cloudflare D1 免費方案 9 月 1 日起超量就失敗：每天讀 500 萬列、寫 10 萬列，用完要等 UTC 午夜

Cloudflare 宣布從 9 月 1 日起，Workers 免費方案的 D1 查詢，超過每日讀取或寫入列數上限就會直接失敗，直到 UTC 午夜重置。資料不受影響，但小專案要先檢查有沒有會全表掃描的查詢。

一句話看懂：Cloudflare D1 免費方案從 9 月 1 日起，每天讀取或寫入超過上限，查詢就會直接失敗，要等到 UTC 午夜才重置；用 D1 做小專案的人要先檢查用量。

D1 免費方案開始強制限額資訊圖卡：每天讀超過 500 萬列、寫超過 10 萬列，查詢就會直接失敗

先用白話講：D1 是什麼？「列數限額」又是什麼？

D1 是 Cloudflare 的資料庫服務，很多人用它搭配 Workers 做小網站、小工具，免費方案就能開始玩。

它不是用「查詢幾次」來算量，而是用「讀了幾列資料」。想像你去圖書館找書：不管最後只借走一本，管理員都按你「翻過幾本書」來計費。如果書架沒有分類（沒有索引），你得從頭翻到尾，翻過的每一本都算數。

Cloudflare 在 9 月 1 日的更新日誌寫道：從這天起，Workers 免費方案的 D1 查詢，只要帳號超過每日讀取列數或寫入列數上限，就會直接失敗。

依 D1 定價頁：

官方文件的例子：一張 5000 列的表，做一次全表掃描，就算 5000 列讀取。如果用沒有索引的欄位過濾，即使只回傳幾列給你的 Worker，資料庫仍然要掃描更多列才能找到答案，這些都算讀取。

假設你的小網站每次請求都對一張 1 萬列的表做全表掃描：每天只要 500 次請求，就會用掉 500 萬列的讀取額度（自行換算）。所以光是替常用的查詢欄位加上索引，就可能讓額度用量差很多倍。

官方建議的檢查方式：

const { meta } = await env.DB.prepare("SELECT * FROM posts WHERE slug = ?")
  .bind(slug)
  .run();
console.log(meta.rows_read, meta.rows_written);

另外，程式也要能處理「額度用盡」的錯誤：官方給的錯誤訊息是 Your account has exceeded D1’s free tier daily row read limit，建議在呼叫端捕捉，並顯示友善的錯誤頁面，而不是整個站掛掉。

我自己做的小工具，不少是用免費方案撐著的，所以這種「額度變成硬限制」的消息我很有感。真正容易踩雷的是沒加索引的查詢，平常流量小看不出來，一旦有爬蟲或突然的人潮，額度就在一天內燒光。

如果你是幫客戶做小型網站，建議在交付前加一個檢查：把最常用的幾個查詢跑一遍，看 rows_read 是不是大到不合理；同時在文件裡寫清楚「免費額度用完會怎樣」，讓客戶知道哪天要升級。

「讀取列數」是怎麼算的？

依官方文件，是查詢掃描了多少列，和回傳多少列無關。一張 5000 列的表做全表掃描，就算 5000 列；用沒索引的欄位過濾，即使只回傳幾列，仍然會掃描更多列。

超過上限會怎樣？

當天剩下的 D1 查詢都會失敗：Workers 綁定與 REST API 都會回傳錯誤，直到 UTC 午夜重置。UTC 午夜相當於台灣時間早上 8 點（自行換算）。已存的資料不受影響。

付費方案的額度呢？

D1 定價頁寫明 Workers Paid 方案每月前 250 億列讀取、5000 萬列寫入包含在內，超出後依量計費，細節請看官方定價頁。

我要怎麼知道自己用了多少？

官方文件列出三個管道：查詢結果裡的 meta 物件、GraphQL Analytics API，以及 Cloudflare 儀表板中資料庫的 Metrics > Row Metrics 頁面。

作者

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