Cloudflare D1 免费额度 9 月 1 日起硬失败，超了当天整个账号查不了

D1 的免费额度数字没变，变的是撞上去之后会发生什么。

9 月 1 日起，Workers Free 上的 D1 在账号当天超出每日行读或行写额度后，查询会直接失败，Workers Binding API 和 REST API 都返回错误，一直到 UTC 零点重置。官方强调了两点：已存储的数据不受影响，超限时会收到邮件提醒。

两条错误原文：

Your account has exceeded D1’s free tier daily row read limit. Upgrade to a paid plan or wait until tomorrow (midnight UTC) to continue.
Your account has exceeded D1’s free tier daily row write limit. Upgrade to a paid plan or wait until tomorrow (midnight UTC) to continue.

额度是多少

按 D1 定价页，免费版是每天 500 万行读、10 万行写，存储 5GB，每日 00:00 UTC 重置。Workers Paid 是每月前 250 亿行读、5000 万行写、5GB 存储，超出部分分别按 0.001 美元/百万行、1.00 美元/百万行、0.75 美元/GB-月计。

“行读”这三个字最容易算错

官方定义写得很清楚：行读算的是查询扫描了多少行，不是返回了多少行。一张 5000 行的表跑一次 SELECT * FROM table 就是 5000 行读；在一个没有索引的列上过滤，可能只返回 3 行，但底下扫了 5000 行，按 5000 算。一次跑 1000 遍，一天的额度就没了。

行写算的是 INSERT、UPDATE、DELETE 影响的行数，插 10 行就是 10 行。DDL（CREATE、ALTER、DROP）会同时产生读和写。行的大小和列数不影响计数，1KB 的行和 100KB 的行都算一行。

还有一条容易忽略：从 Dashboard 和 Wrangler 里跑的查询也算用量。一个共享的免费账号，额度可能在没人看的时候被 CI、压力测试或者你自己手抖的一次全表扫描吃掉。

今天该做的

看 meta 对象里的 rows_read / rows_written，或者在 Dashboard 的 Metrics → Row Metrics 里按库、按时间段看。别拿”返回了多少条对象”当用量。
给高频查询加 EXPLAIN QUERY PLAN。看到 SCAN table_name 就是全表扫描，目标是让它变成 SEARCH table_name USING INDEX。
给过滤、join、group by 用到的列加索引。索引会让写这些列时多写一行（表一行、索引一行），但读的降幅通常远大于这点代价。
判断要不要升 Paid。官方说升级通常几分钟生效，5 美元/月把”每天可能停一次”变成”按月计费”。这不是超量不超量的决策，是可用性决策。

泼冷水

如果你的 side project 一天几百次查询、表也就几千行，这条改动跟你没关系，别被”会硬失败”吓到去升级。

真正的风险在两种场景：一个跑在免费 D1 上但对外的产品，和把预发、CI、测试都塞在同一个 Cloudflare 账号里的团队。后者尤其容易被打中——额度是账号级的，一个跑批任务就能把生产本来要用的余量提前花光，而出事的时候你还在查应用日志，想不到是隔壁的定时任务干的。