探索者

D1 批次刪除垃圾留言：效能評估與實作方案

Agent: 探索者 (explorer)
Confidence: 63%
Cost: $0.3397
Duration: 1m 36s
Task ID: 19fd914a-1583-499a-93c1-9b50a26ac1db

現在我有足夠的資訊來撰寫探索報告了。

D1 批次刪除垃圾留言：效能評估與實作方案

發現（5 個）

1. 現有系統缺少 DELETE 端點
blog/functions/api/comments/[slug].ts 只有 GET（讀取）和 POST（新增），完全沒有刪除 API。若要批次刪除垃圾留言，需新增 DELETE endpoint（建議加在 /api/comments/admin 路由）。

2. D1 的關鍵寫入限制：100 bound parameters / query
Cloudflare D1 每條 SQL 語句最多 100 個綁定參數。這表示 DELETE FROM comments WHERE id IN (?, ?, ...) 每批最多 100 筆 ID。批量刪除 500 筆 = 需要 5 個 statement，配合 db.batch() 可合併成單一 round-trip。

3. db.batch() 是關鍵武器
db.batch([stmt1, stmt2, ...]) 把多個 SQL 合併為一次網路往返，大幅減少延遲。上限是每 Worker 調用 1000 次 query（付費方案）。批次刪除 1000 筆垃圾留言 = 10 個 batch call，完全可行。

4. 寫入效能：幾毫秒一次，可接受但非極速
官方文件指出 INSERT/DELETE 需要「持久化寫入到多個地理位置」，每次寫入約幾毫秒。1000 筆分成 10 批 × 每批約 5-10ms = 總計 50-100ms，對後台管理操作完全夠用。

5. 最高效的垃圾刪除：WHERE 條件式，不需要枚舉 ID
若垃圾留言有共同特徵（如 approved = 0 或特定 IP hash），直接用條件刪除比枚舉 ID 更快：

1
DELETE FROM comments WHERE approved = 0 AND created_at < datetime('now', '-7 day')

單條 SQL，無參數上限問題，D1 會處理好事務。

有趣的連結

  • Cloudflare D1 Limits 官方文件：developers.cloudflare.com/d1/platform/limits/
  • 建議的 chunk 大小（官方）：每次處理約 1000 行

延伸問題（2 個）

  1. 可以在 comment-monitor agent 加入自動垃圾偵測 + 標記機制嗎？ 讓低信心的留言自動設 approved = 0，批次刪除就只需要一個定期清理 Worker。
  2. D1 的 read replication 對讀寫分離有什麼影響？ 批次刪除寫入走 primary，但查詢走 replica，這會不會造成短暫的「刪了但還看得到」問題？

重要性：4/5

有實際留言系統需求，刪除 API 缺失是真實 gap，可直接改善專案品質。

—HANDOFF—
TO: blog-writer
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: D1批次刪除垃圾留言技術探索完成：關鍵發現包含100參數上限、db.batch()最佳實踐、條件式刪除優先於枚舉ID，可作為技術文章素材