关于CloudFlare D1 SQL和KV存储的研究

实验背景

今天向由 Cloudflare 搭建的图床（CloudFlare-ImgBed）里一次性存储了 4000 多个文件。

4000 多个文件本身并不算特别大，大多数文件大小在几十 MB 到一百多 MB 之间。

需要注意的是，这个图床中的 D1 和 KV 并不是实际的文件存储后端，而是主要用于页面索引和相关设置的存储。实际文件存储在 Hugging Face Datasets 和 Discord 频道中。

文件上传过程

一开始上传时，4000 多个文件经历了不断报错、不断成功上传的过程。

根据实际情况，这些报错应该主要来自 Discord 和 Hugging Face 的速率限制。

在完整写入之后，加上此前已经存在的文件，总文件数量大约达到了 7500 个。

D1 消耗异常

在尝试访问图床时，由于页面需要大范围索引约 7500 个文件的路径，D1 的消耗速度突然变得非常快。

最后 Cloudflare 向我发送了邮件，提示 D1 超出了额度。

比较有意思的是，Cloudflare 并没有在刚刚超过额度时立即返回错误，而是一直允许继续使用，直到实际使用量达到大约 127000 次之后才开始出现 429。

也就是说，实际使用量明显超过了原本看到的额度。

尝试使用 KV

之后又尝试使用 KV。

因为 KV 和 D1 在这个场景下都可以承担类似的索引或设置存储功能，所以想通过 KV 来降低 D1 的消耗。

但结果是 KV 的额度同样很快被消耗完了。

尤其是 KV 的写入额度只有 1000 次，在这种大规模索引场景下非常容易达到限制。

达到额度后的影响

比较严重的是，当 KV 和 D1 都达到限制之后，图床甚至出现了无法正常登录的情况。

也就是说，这些服务不只是影响某一个页面的数据读取；当核心索引或设置依赖的存储服务无法继续工作时，整个应用的部分基础功能都会受到影响。

初步结论

这次实验让我发现，对于包含大量文件索引的应用来说，D1 和 KV 的额度并不只是一个单纯的数字问题。

如果一次页面请求需要处理大量索引数据，那么即使实际文件本身并没有存储在 D1 或 KV 中，也可能因为索引操作产生大量数据库访问。

本次大约 7500 个文件的实际测试中，D1 最终在约 127000 次使用后触发 429，而 KV 的写入额度则很快达到 1000 次限制。

因此，在设计这类图床或文件管理服务时，需要特别注意：

• 不要在一次请求中无差别索引大量文件。

• 对高频访问的数据进行缓存。

• 根据数据特点选择 D1、KV 等不同存储方式。

• 避免让登录、配置等核心功能完全依赖容易达到额度上限的存储操作。

• 对大规模文件索引进行分页、缓存或其他优化。

这次测试也算是一次比较真实的 Cloudflare D1 / KV 压力测试记录。