Cloudflare 的 D1 資料庫服務正面臨來自生產環境中部署該服務的開發者的大量批評，許多人報告稱儘管嘗試了最佳化，但效能依然持續不佳。雖然最近一篇文章詳細介紹了最佳化 D1 資料庫查詢的各種技術，但社群反饋表明，這些最佳化可能不足以克服基本架構限制。
全球效能問題
來自多個地區的開發者報告稱，Cloudflare D1 的響應時間持續緩慢，簡單查詢通常需要 200-400ms 或更長時間才能完成。這種效能問題在歐洲以外地區尤為明顯，一些使用者報告在北美地區的響應時間甚至飆升至 500ms 或更高。Cloudflare 網路的全球分佈通常是其他產品的優勢，但似乎無法克服 D1 的架構限制，因為資料庫儲存在單一主要區域，許多操作需要跨資料中心通訊。
「我幾個月前為一個專案評估了 D1，發現全球效能非常糟糕。我不確定他們架構的具體問題是什麼，但如果檢視首位元組時間（TTFB）資料，你會發現即使對於 D1 演示資料庫，歐洲以外地區的資料也很糟糕，甚至在歐洲內部，TTFB > 200ms 也不算好。」
D1開發者報告的效能問題：
- 簡單查詢通常需要200-400毫秒以上才能完成
- 北美地區的響應時間飆升至500毫秒或更高
- 使用 CF Workers + D1 的查詢響應時間在300-3000毫秒範圍內
- 相比之下，CF Workers + 託管 PostgreSQL 的響應時間在50-100毫秒範圍內
已識別的架構限制：
- 資料庫儲存在單一主要區域用於所有寫入操作
- 冷啟動需要建立連線
- 快取未命中需要從主要區域獲取資料
- 基於 SQLite 構建，寫入併發能力有限
- 缺乏從主要區域到邊緣的主動結果快取
架構限制
一些開發者已經確定了可能導致 D1 效能問題的特定架構特性。這些包括資料庫儲存在單一主要區域（所有寫入操作必須在此處理），冷啟動涉及連線建立開銷，以及本地副本中的快取未命中需要從主要區域獲取資料。此外，D1 基於 SQLite 構建，在分散式環境中寫入併發性存在已知限制。缺乏從主要區域到邊緣位置的主動結果快取進一步加劇了這些問題。
最佳化技術與根本問題
原文詳細介紹了幾種最佳化技術，包括使用批次請求、從更新操作中排除 ID、避免全表掃描、拆分多表連線以及最佳化多記錄插入。雖然這些技術可能有助於減少行讀取並提高查詢效率，但社群反饋表明它們無法解決核心延遲問題。許多開發者報告稱，即使實施了類似的最佳化，響應時間對於生產應用程式仍然高得令人無法接受。
D1最佳化技術推薦：
- 對多個數據庫操作使用批處理
- 在更新操作中排除ID欄位
- 避免對計數查詢進行全表掃描
- 將多表連線拆分為單獨的查詢
- 對批次操作使用分塊多記錄插入
- 啟用 Smart Placement 以略微提高效能
D1適用場景：
- 擁有少於5個表且JOIN操作最小化的小型專案
- 頁面訪問計數
- 郵件列表
- 網站頁面瀏覽跟蹤
- 高讀取、低寫入且具有積極快取策略的場景
有限的使用場景
鑑於效能限制，開發者發現 D1 的實際應用比最初希望的更為有限。一些人建議它可能只適用於特定場景，如高讀取、低寫入且具有積極快取策略的應用，或關係複雜性有限的非常小型的專案。幾位使用者指出，D1 最適合簡單用例，如頁面訪問計數、郵件列表或網站頁面瀏覽跟蹤，這些場景不需要複雜的連線且表大小保持適中。
替代方案和比較
許多評估過 D1 的開發者最終選擇了替代解決方案。幾位評論者提到使用 Cloudflare Workers 配合傳統託管 PostgreSQL 資料庫能獲得明顯更好的效能，報告查詢響應在 50-100ms 範圍內，而 D1 則為 300-3000ms。其他人則建議，對於需要真正資料庫功能的應用，傳統資料庫解決方案的初始較高成本可能會被減少的工程時間所抵消，否則這些時間將花在處理無伺服器陷阱和可能不可預測的計費上。
智慧放置和未來改進
一些使用者報告稱，在啟用 Cloudflare 的智慧放置功能後效能略有改善，該功能嘗試最佳化 worker 執行位置。然而，即使啟用了此功能，許多人仍然認為效能不足以滿足生產應用程式的需求。一些開發者表示希望 D1 的效能問題可能會在未來更新中得到解決，暗示當前實現可能優先考慮上市時間而非效能最佳化。
總之，雖然 Cloudflare D1 提供了一個與其 Workers 平臺整合的吸引人的無伺服器資料庫選項，但當前的效能限制似乎足夠顯著，以至於許多開發者正在尋找其他生產應用程式解決方案。文章中詳述的最佳化技術可能有助於提高效率，但似乎無法解決導致延遲問題的基本架構限制。目前，D1 似乎最適合特定用例，即效能要求適中且資料庫複雜性有限的場景。