Cloudflare 在 2026 年 10 月 30 日公告，D1 將從 11 月 4 日起對單次查詢結果執行 50 MB 上限。回傳內容超過限制時，查詢會失敗並出現 D1 query result exceeded the maximum response size limit of 50 MB。官方表示此限制涵蓋其觀察到的 99.999% 請求，因此大多數應用不受影響；但報表下載、後台全量列表、資料同步與把 BLOB 一次讀回的功能，仍應在生效前主動檢查。

這不是資料庫總容量降到 50 MB，也不是每月流量或資料列讀取額度。限制的單位是「一次 SQL 查詢所產生的結果」，D1 的資料庫大小、列大小、CPU 時間與方案用量仍是不同邊界。把這些限制混在一起，可能導致團隊誤以為升級方案就能解決，或為了避開結果上限把同一個昂貴查詢重跑很多次。

先找出可能回傳大量資料的路徑

Cloudflare 公告明確點出兩個優先修正：不要使用不必要的 SELECT *，並以 LIMIT、OFFSET 拆分大型結果。盤點時不要只搜尋 SQL 字串，還要從產品功能反查：管理後台的「顯示全部」、CSV 下載、每日資料倉儲同步、跨店報表、附件或圖片欄位、無上限的搜尋 API，都可能藏著大結果。

建立清單時記錄查詢名稱、呼叫端、選取欄位、一般與極端資料量、是否對外回應、失敗後能否重試，以及是否有排序鍵。測試資料不能只放幾十筆；應以正式環境的欄位寬度與成長速度建立接近上限的資料集。尤其 JSON、長文字和 BLOB，資料列數看似不大，序列化後仍可能快速放大。

如果已有查詢監控，先找回傳列數、執行時間與讀取列數的高峰，再逐一重播。沒有結果 bytes 指標時，可在測試環境將結果序列化後量測大小，但這只是風險篩選；最終仍要讓查詢本身維持在平台限制內，不能只在應用收到結果後才截斷。

線上列表應採穩定游標，而非無限放大頁面

一般 API 應只選畫面需要的欄位，詳情再以 ID 查詢。分頁若使用 LIMIT 與 OFFSET，實作簡單，適合小型、低頻後台；但資料持續新增或刪除時，使用者可能看到重複或漏列，越後面的頁面也可能需要掃描更多資料。

訂單、事件或日誌等持續成長資料，較適合 keyset pagination。選擇穩定且有索引的排序組合，例如 created_at, id，下一頁帶回上一頁最後一筆的兩個值，再查詢小於或大於該游標的資料。若只用非唯一時間，數筆資料同秒寫入時仍會漏資料；若排序欄位會被更新，頁面間也可能跳動。

對外 API 應設定明確的最大 page_size，拒絕任意大的值，回傳 next_cursor 並記錄查詢版本。切換分頁契約時，可先保留舊參數但套用上限，提供一段相容期；若直接把原本的全量陣列改成分頁物件，既有前端、排程與合作夥伴整合可能在資料庫上限生效前就先壞掉。

匯出工作不要偽裝成一般 API 請求

大量 CSV 或備份通常不是互動式列表，應拆成非同步工作：建立 export job、固定查詢範圍、分批讀取、逐段寫入物件儲存，完成後產生有期限的下載連結。每批保存最後游標、筆數、檔案 checksum 與工作狀態，失敗時從確認點繼續，而不是從頭重跑。

官方公告說明，透過 REST API 的 import 與 export 作業不受這次 50 MB 查詢結果限制；這不等於任意 REST 查詢都沒有上限，也不代表瀏覽器應直接承接巨大回應。若需求其實是資料備份或搬移，應評估正式 export 流程；若是客製報表，仍需設計分批、權限、資料遮罩、保留期限與取消機制。

把大欄位移到 R2 等物件儲存可能降低資料庫結果大小，但不是看到 50 MB 就立即拆庫的唯一答案。先確認 BLOB 是否真的需要在每次列表回傳、是否可改存 object key，以及刪除與存取權限如何同步。資料庫保存可搜尋 metadata、物件儲存保存檔案內容，通常比在每列載入完整檔案更容易控制。

錯誤處理不能用重試掩蓋設計問題

D1 除錯文件已列出新的錯誤文字與建議做法。結果超過 50 MB 是可重現的查詢設計錯誤，原參數不變時重試不會變小；無限重試只會增加讀取、延遲與佇列壓力。應將此錯誤分類成不可直接重試，回報查詢識別、篩選範圍與頁面大小，並引導呼叫端縮小區間或改用匯出工作。

同時要區分暫時性網路錯誤與結果上限。讀取操作可在有限次數內退避重試；寫入操作則要先確認冪等性。Cloudflare 也提醒，D1 binding 沒有每次呼叫的取消機制；即使用應用層計時器停止等待，後端寫入仍可能完成，因此不能把 timeout 一律視為沒有提交。

11 月 4 日前的上線與驗收順序

先在測試環境為高風險查詢加入欄位白名單與最大頁面大小，再建立接近正式資料量的回歸案例。驗收至少包含第一頁、中間頁、最後一頁、同排序值、分頁途中新增或刪除、空結果、大文字欄位，以及超過用戶可接受時間的匯出取消。對照拆分前後的總筆數、唯一 ID 與聚合值，確認沒有漏列或重複。

部署時先更新能理解分頁格式的呼叫端，再縮小服務端回應；外部整合無法同步更新時，建立有期限的舊版端點並監測使用量。告警要能看出是哪一支查詢觸發上限，而不只是整體 HTTP 500。回滾可恢復舊程式，但 11 月 4 日後不能回滾平台限制，因此舊版若仍會產生巨大結果，不能當成可靠退路。

D1 限制文件同時列出單一資料庫大小、查詢時間、列大小與 subrequest 等其他邊界。這次事件最值得做的不是只把 50 MB 寫進常數，而是把「線上查詢、互動式列表、批次匯出、檔案儲存」分成不同路徑。查詢只取需要的欄位、分頁具有穩定游標、匯出可續跑，才不會在資料成長後反覆撞上下一個平台限制。