https://benzhub.github.io/tags/%E8%B3%87%E6%96%99%E5%BA%AB/Recent content in 資料庫 on BenzHubHugozh-TWFri, 21 Aug 2026 00:00:00 +0000https://benzhub.github.io/post/cloudflare/021-d1-sessions-api/Fri, 21 Aug 2026 00:00:00 +0000https://benzhub.github.io/post/cloudflare/021-d1-sessions-api/<blockquote> <p>上一篇《<strong>D1 Migrations</strong>》我們學會了像 <strong>Git</strong> 一樣安全地演進資料表結構。但當你的應用擴張到全球、讀取流量湧入,新的問題浮現:主要資料庫(<strong>Primary</strong>)在美國西部,新加坡的使用者每次讀取都要繞半個地球,延遲高得惱人。<strong>D1</strong> 的 <strong>讀取複本(Read Replication)</strong> 讓你在全球六個地區部署唯讀副本,使用者就近讀取;而 <strong>Sessions API</strong> 則是啟用複本的鑰匙,並透過 <strong>書籤(Bookmark)</strong> 機制,在「低延遲」與「一致性」這對天生矛盾之間取得平衡。這篇我們把 <code>env.DB.withSession()</code> 的 <code>first-primary</code> / <code>first-unconstrained</code> 兩種模式、<code>read-your-writes</code>(讀取自身寫入)、書籤的跨請求傳遞,以及成本與一致性的權衡一次講透。</p> </blockquote>https://benzhub.github.io/post/cloudflare/019-d1-intro/Wed, 19 Aug 2026 00:00:00 +0000https://benzhub.github.io/post/cloudflare/019-d1-intro/<blockquote> <p>上一篇《<strong>R2 物件儲存</strong>》我們把「大型檔案」搬上了雲,但很多應用真正需要的其實是<strong>結構化的關聯式資料</strong>:使用者表、訂單表、商品表,要能用 <strong>SQL</strong> 做 <code>JOIN</code>、<code>WHERE</code>、交易——這是 KV 和 R2 都不擅長的。這一塊,Cloudflare 交給了 <strong>D1</strong>:一個底層是 <strong>SQLite</strong>、跑在**邊緣(edge)**的 <strong>Serverless</strong> 關聯式資料庫。這篇我們從什麼是 D1、怎麼用 <code>wrangler d1 create</code> 建庫 + binding、<code>wrangler d1 execute</code> 建表,到查詢核心 <code>prepare</code> / <code>bind</code> / <code>first</code> / <code>all</code> / <code>run</code>、<code>batch</code> 交易、參數化查詢防注入,以及本地 vs 遠端的差別,一路帶你在 Workers 裡用熟悉的 SQL 查資料。</p> </blockquote>