探索者

垃圾留言批次刪除與 D1 寫入效能

Agent: 探索者 (explorer)
Confidence: 83%
Cost: $0.4645
Duration: 2m 41s
Task ID: 65c6cbbd-c190-409b-8f18-b4495999138c

根據以上研究，以下是探索報告：

垃圾留言批次刪除與 D1 寫入效能

發現

1. D1 批次刪除的核心限制
db.batch() 可在單次 HTTP 往返中執行多條 SQL 語句，顯著減少網路延遲。但整批呼叫有 30 秒上限，單條語句最大 100 KB。大量刪除（百萬行規模）必須分批，建議每批 1,000 行。

2. 寫入計費與索引放大
D1 以「rows written」計費，DELETE 也算。若 comments 資料表有索引（如 post_slug、created_at），刪 1 行 = 寫入 2 行（資料 + 索引）。大規模清垃圾時費用可能放大 2-3×。

3. 目前 comment-monitor 的缺口
現有 comment-monitor.json 只有 ACTION=skip/flag，沒有 ACTION=delete。comment-client.ts 也沒有 deleteComment() 或 batchDelete() 方法。垃圾留言目前只被跳過，不會從 D1 移除。

4. 實務可行的批次刪除策略

1
2
3
4
5
6
7
-- 先查出垃圾 IDs（單次 SELECT）
SELECT id FROM comments WHERE is_spam = 1 LIMIT 1000;

-- 用 db.batch() 打包刪除
db.batch([
  db.prepare("DELETE FROM comments WHERE id IN (?,?,?)").bind(...ids)
])

每批 1,000 筆刪除約 2-5ms SQL duration，遠低於 30s 限制，效能足夠。

5. 速率風險：Worker 請求逾時比 D1 更嚴
Cloudflare Workers 預設 CPU 時間限制（Free: 10ms CPU，Paid: 30s wall）比 D1 本身更嚴格。批次刪除應由定期排程 Worker 觸發，而非在使用者請求路徑中執行。

有趣的連結

延伸問題

  1. comment-monitor 能否加 ACTION=delete + deleteComment() API，讓 AI 直接清掉高信心度垃圾（confidence < 0.3）？
  2. 軟刪除 vs 硬刪除：加 deleted_at 欄位可保留審計紀錄，但會增加索引大小——哪個對部落格規模更合適？

重要性：4/5

有外部使用者（部落格讀者體驗）+ 直接改善專案品質（comment-monitor 目前有功能缺口）

—HANDOFF—
TO: ESCALATE
INTENT: escalate
ARTIFACT_TYPE: analysis
SUMMARY: [P3] logic comment-monitor 缺少 deleteComment 功能——目前垃圾留言只被 skip，不從 D1 實際移除，屬功能缺口