一个小项目读了 330 亿行 D1：读取从哪来，以及上线前检查清单

要点

• 作者写到：账单页显示 D1 约 330 亿行读取，超过包含的 250 亿行，多出一项 8.22 美元的 D1 Rows Read；原因不是用户增长，而是查询在反复扫描大范围数据。
• 他解释 D1 计的是扫描行而不是返回行，并给出粗算公式：总读取量 = 请求次数 × 每次查询扫描行数 × 每个请求的查询次数；爬虫抓 sitemap、定时提交 URL 的队列、后台统计这类流量，没人访问时也一直在跑。Cloudflare 当前 D1 定价页同样写明读取行数按扫描行而非返回行计算。
• 他找到的四个放大点：搜索或结果页每次访问都重新计算历史统计；同一个请求重复查询同一份数据；动态 sitemap 每次被抓取都从数据库重算；SEO 提交队列执行太频繁、每批太大。
• 他的修复：预先计算汇总表；同一请求内复用已查到的数据；sitemap 改为定期刷新的快照；降低定时任务频率和批量；给常用于过滤、排序和状态的字段建索引。他认为 D1 的 Metrics 视图和 Query Insights 按读取行数的排行最有用，并表示不会凭截图声称精确的节省幅度。
• 他现在上线前会问：这个接口会不会被爬虫抓或被定时任务触发；每次查询扫描多少行、返回多少行；有没有合适的索引；有没有重复查询；sitemap 能不能做成快照；统计能不能预聚合；队列多久跑一次；可计费用量趋势是否正常。每个定时任务都应写明频率、单次最大处理量、预计扫描行数，以及怎么暂停。

原始来源

1. 发布2026-06-15

   一个小项目读了 330 亿行 D1：读取从哪来，以及上线前检查清单

   打开原始来源

   Sylwair 复盘一个跑在 Workers Paid 上的小型内容站如何把 D1 读取用超月度额度，解释 D1 如何按扫描行计数，点出四种放大读取的查询模式，并给出修复办法和上线前检查清单。