Cloudflare D1 免费额度触顶后会怎样？查询将直接停止

从 2026 年 9 月 1 日起，Cloudflare D1 免费额度不再只是用量问题，而是会直接影响生产可用性的技术决策。账户一天内读取达到 500 万行或写入达到 100,000 行后，D1 查询可能停止，直至 UTC 零点。

Cloudflare D1 免费额度没变，触顶后的处理变了

免费配额早已有之。现在改变的是配额用尽后会发生什么。

在 Workers Free 上，只要任一每日额度被用尽，D1 就会同时通过 Workers Binding API 和 REST API 拒绝查询。Cloudflare 针对读取和写入上限分别给出了报错信息，并说明配额在 00:00 UTC 重置后，查询才会恢复。已存储的数据依然完好，但应用可能无法读取或修改这些数据。

这正是问题的核心：原本只是软性的用量数字，如今成了决定服务可用性的硬边界。

达到每日上限时，Cloudflare 会发送电子邮件。它能解释事故为何发生，却是在数据库已经不可用之后才到达。生产团队需要的是预算和更早的预警，而不只是故障发生后的说明。9 月 1 日的 D1 更新日志 列出了确切的失败行为和错误文本。

Workers Paid 不受这项每日停用规则影响。只要原型始终远低于两项额度，现在未必需要迁移；但对于依赖 D1 的线上产品，Free 必须像任何存在停机点的资源一样管理。

Cloudflare D1 查询限制真正计算的是扫描行数

读取额度不是 500 万次 API 调用，也不是返回 500 万条记录，而是数据库为完成查询而扫描的 500 万行。

假设某个筛选只返回一位客户，但没有可用的索引。D1 可能需要扫描一张包含 5,000 行的表才能找到这条记录。这样的查询运行 1,000 次，就会耗尽每天 500 万行的读取额度。结果看起来很小，底层付出的工作量却不小。

写入的计算更直接。INSERT、UPDATE 或 DELETE 会按发生变更的行数计入写入量。一次插入 10 行，就算写入 10 行。CREATE、ALTER 和 DROP 等架构操作也可能同时消耗读取和写入额度。

行大小不会改变这个计数。1 KB 的行和 100 KB 的行都各算一行；真正影响读取数字的是查询方式。

索引让 D1 直接定位相关记录，无需扫描整张表。通常代价是增加少量写入，却能大幅减少读取。写入一个被索引覆盖的列时，D1 会写入表记录以及至少一条索引记录。因此，应该为频繁用于筛选和连接的列建立索引，而不是给所有列一股脑加索引。

Cloudflare 的索引指南提供了一个直接的检查方法：在高成本查询前加上 EXPLAIN QUERY PLAN。执行计划显示 SCAN，说明正在扫描表；显示 SEARCH ... USING INDEX，说明查询使用了索引。添加索引后，再运行 PRAGMA optimize，让查询规划器掌握最新统计信息。

真正变化的是业务账

Workers Free 仍然是 $0。变化在于代价：数据库账单的上限仍是零，但数据库可能在 UTC 当天剩余时间里停止为应用提供服务。

Workers Paid 的起步价是每个账户每月 $5。它用按月计算的包含用量和超额计费，替代了每日硬停止。

从 Free 升到 Paid 的跨度比乍看之下更大。连续 30 天用满 Free 的读取额度，总计是 1.5 亿行，只占 Paid 套餐每月所含 250 亿行读取量的 0.6%。连续 30 天用满 Free 的写入额度，总计是 300 万行，相当于每月所含 5,000 万行写入量的 6%。

因此，对许多小型应用来说，第一次付费并不是为了超额用量，而是花 $5 购买可用性。Workers 请求、CPU、超过 5 GB 的 D1 存储空间以及其他 Cloudflare 产品仍有各自的计量方式，所以 $5 只是下限，并不代表整个账户的费用一定恰好是 $5。更完整的 Cloudflare 定价评测梳理了账户与各产品计费边界之间的区别。

D1 不收取数据传输费或吞吐量费用。这并不能减轻 Free 触顶后的影响，只说明在这项决策中无需考虑出口流量费用。

四类团队，四种务实做法

运营线上 SaaS 的独立开发者

如果登录、账单状态或客户控制台需要读取 D1，那么 Free 套餐已经把生产停机风险带进了业务。先找出正常运营时最繁忙的一天，再修复所有全表扫描。如果应用仍然接近上限，每月最低 $5 的成本，也比面对无法预知会持续多少小时的数据库中断更划算。

它的价值并不是抽象意义上的数据库容量增加，而是把“等到 UTC 零点”从事故恢复方案中删掉。

一个账户管理多个数据库的代理服务商

限制条款针对的是账户级别。代理服务商应盘点该 Cloudflare 账户下的每一个 D1 数据库，而不是只检查某个客户项目就认定整个账户安全。

先用每个数据库的指标找出用量异常的项目，再汇总所有数据来设定账户预算。这样，运维团队就有一个可以负责的共享数字；某个项目的低效扫描，不应变成同一账户下另一个项目毫无征兆的宕机。

排查高成本读取的后端工程师

要找的是查询模式，而不是随意删除数据。D1 会在每次查询的 meta 对象中返回 rows_read 和 rows_written，这些数值能够显示单次执行的精确用量。

Cloudflare 还通过 Wrangler 和 GraphQL Analytics API 提供查询洞察。按读取量排序，找出反复出现的扫描，检查执行计划，添加针对性索引，然后再次测量。一次改动既能减少额度消耗，通常也能降低延迟。

负责导入或同步任务的运维负责人

一次批量同步可能在客户流量接触数据库之前，就耗尽 100,000 行写入额度。非紧急任务可以跨多个重置窗口分批执行；生产环境导入前，也可以把账户升级到 Paid。

不要指望触及写入上限后再做清理。DELETE 本身也是写入操作，同一份已经耗尽的额度会让清理查询同样被阻止，直至重置。这样安排的价值，是在批处理运行期间继续为线上业务保留写入能力。

在警报到来前，先给 Cloudflare D1 免费额度设预算

下面是一套可执行的初始策略。它是运维规则，并非 Cloudflare 的要求：把生产预算设为官方 Free 配额的 80%。也就是说，每天的运营上限是读取 400 万行、写入 80,000 行，另外保留 100 万行读取和 20,000 行写入，用于应对突发流量和监测延迟。

1. 1

   测出真实的一天

   打开 Cloudflare，进入 D1，逐一选择数据库并打开 Metrics。默认视图显示最近 24 小时。调取足够长的历史数据，覆盖普通工作日、产品发布、数据导入和流量高峰。D1 会保留 31 天的这些指标。

2. 2

   找出消耗行数的查询

   测试关键路径时，查看每条查询的 meta.rows_read 和 meta.rows_written。利用查询洞察，对高频或高成本语句排序。对读取开销最大的查询运行 EXPLAIN QUERY PLAN，先修复全表扫描，再判断升级套餐是否是唯一答案。

3. 3

   在硬上限之前预警

   使用 GraphQL Analytics API 定时检查账户；它读取的正是控制台所用的数据集。读取达到 400 万行或写入达到 80,000 行时通知负责人。Cloudflare 在额度用尽时发送的邮件，仍可用来确认事故，但不应成为生产环境的第一个信号。

4. 4

   提前写好失败处理方案

   现在就决定 D1 抛出额度错误时 Worker 应返回什么。如果缓存读取不会再次执行 D1 查询，它仍可能可用；写入路径则需要明确返回不可用状态，或使用单独设计的队列。不要对额度错误循环重试，因为它要到 UTC 零点或完成升级后才能恢复。

D1 指标文档将 rowsRead 和 rowsWritten 列为 GraphQL 字段，并确认控制台使用相同的分析数据。小团队由此既有今天就能执行的手动路径，也有数据库重要到需要通知值班人员时可自动化的路径。

这些解决方案也有明确边界

索引并非没有成本。它会占用存储空间，并在索引值变化时增加写入。只添加能够消除高成本扫描的索引，然后重新测量读写之间的平衡。如果账户已经接近 100,000 行的写入上限，不加选择地建立索引反而可能得不偿失。

Paid 也并非无限使用。它每月包含 250 亿行读取和 5,000 万行写入，超出后按公开价格计费。升级通常会在几分钟内解除 Free 的每日停用，但仍需监控低效查询，并预测 Workers 账单的其他部分。Cloudflare 的当前 D1 定价页是运行手册中应长期保留的数据表。

这里还有一处值得了解的版本记录差异。2025 年 1 月的一则 D1 发布说明称，限制会从 2025 年 2 月 10 日开始执行；较新的专项更新日志则称，执行时间是 2026 年 9 月 1 日。本文以较新的页面为准，因为它直接说明了当前这次上线。这也解释了为何旧的搜索结果可能显示另一个日期。

最后，“存储的数据不受影响”不等于“产品运行正常”。数据可以安然无恙，但所有需要访问它的路由仍可能返回错误；对业务而言，真正的后果是可用性下降。

周一该怎么做

如果面向客户的应用运行在 Workers Free 上，而且请求链路会访问 D1，就应在本周行动。先测量，再修复明显的扫描，把读取 400 万行和写入 80,000 行设为预警线，并预先授权每个账户每月最低 $5 的 Paid 升级。

如果只是可随时丢弃的原型，31 天的历史用量始终远低于运维预算，而且一天无法查询也不会影响客户或收入，可以暂缓升级。不过，预警仍应保留，因为流量和表规模都会改变读取量。

如果账户已经使用 Workers Paid，或应用根本不查询 D1，则不受这项每日停用规则影响。

周一要做的事情很简单：打开每个数据库的 D1 Metrics 标签页，记下账户单日最高的读取量和写入量，找出扫描行数最多的查询，并明确授权一位负责人执行升级。如果修复查询后，正常峰值仍超过读取 400 万行或写入 80,000 行，当天就把账户迁移到 Workers Paid。

如果希望把下一次平台变化也转化为可执行的运维决策，欢迎订阅邮件通讯。