免费 Cloudflare 只有 10 个 D1？满了之后的「穷鬼打法」：表前缀复用同一个库

免费 Cloudflare 只有 10 个 D1满了之后的「穷鬼打法」表前缀复用同一个库上新站的时候最容易踩的坑之一是Workers 免费档每个账号最多只能建 10 个 D1 数据库。官方 limits 写得很清楚Databases per account —— Paid 很多Free 就是 10。图注Cloudflare D1 官方限额免费档最多 10 个数据库满了之后长什么样额度一满再想给新项目「新建一个 D1」就会直接卡住。预览/部署侧常见提示大概是这样当前账号 D1 免费额度已满例如已经有 11 个库没法再 createKV / R2 / Queues 可能都备好了就差这一步。图注D1 免费额度已满、无法新建库的提示用 API 把账号里现有的库拉出来一眼就能看到已经顶满本例 11 个共享业务库下文用shared-app-db指代真实库名已打码图注本账号 D1 列表API 实拉这时候有两条路删掉 12 个不用的库或者升级 Workers Paid穷鬼打法不再新建库多个站点共用同一个 D1用表名前缀把数据隔开下面讲第 2 条。穷鬼打法一个 D1多个前缀核心就一句话库还是那一个每个站点给自己的表加固定前缀bb_、rd_、fr_……迁移表也用各自的*_d1_migrations。这样不占用新的「数据库名额」还是 1 个 D1算进那 10 个里的同一个站点之间表不撞名每个 Worker 仍然binding: DB指到同一database_id1改表前缀项目里通常有一个很小的配置文件例如图注TABLE_PREFIX 配置示例/** 所有表/索引共用此前缀多个站点绑同一个 D1 */exportconstTABLE_PREFIXbb_;换站点就换前缀rd_、fr_、jp_……一个前缀对应一个产品别复用。2Wrangler 复用已有库而不是 create新建站时不要再跑「创建 new D1」。直接把d1_databases指到已经存在的那一个并指定本站自己的 migrations 表图注wrangler 复用已有 D1 配置{ d1_databases: [{ binding: DB, database_name: shared-app-db, database_id: 已有库 uuid, migrations_dir: drizzle, migrations_table: bb_d1_migrations }] }注意两点database_id用已有库的 UUIDmigrations_table必须带本站前缀bb_d1_migrations/rd_d1_migrations……否则多家迁移会互相踩3同一库里看起来像这样共享库里会并存多套「平行宇宙」表示意图注同一 D1 内多套前缀表示意-- 站点 A bb_user bb_order bb_credit bb_d1_migrations -- 站点 B rd_user rd_order rd_credit rd_d1_migrations -- 站点 C fr_user fr_order fr_credit fr_d1_migrations实际能撑多少站免费档限制的是「数据库个数」不是「表的个数」。所以理论上1 个共享 D1 × N 个前缀 ≈ N 个站点的业务表仍然只占 1 个名额。我们这边就是这个路数账号 D1 列表已经顶满免费档新站继续绑同一个共享库、换前缀上线——不是鼓励大家永远不升级而是额度卡住时还能继续发版。模型侧调用的话我平时会顺手走 tryallapi.com 这类聚合接口和「库满了换前缀」是两件独立的事互不耽误。注意事项别省出事故前缀一定要全局唯一两个站共用bb_等于两套业务写同一批表。migrations_table 也要带前缀否则 migration 历史串台。共享库有整库 500MBFree和账号存储上限站多了要盯容量不是无限囤。当天row read / row write免费额度是账号级的站一多更容易顶满——这和「库个数」是另一道墙。备份 / Time Travel / 误删风险共用库操作前看清楚前缀。真要隔离合规或大流量该升级 Paid、该拆库还是拆穷鬼打法是过渡方案。小结做法效果每站新建一个 D1免费档最多约 10 站就顶满删库 / 升级 Paid合规、省心但要动手或花钱表前缀 复用同一 D1不占新名额继续上站所以免费 CF 只有 10 个 D1 时满了怎么办别再 create 了——给表加前缀挤进同一个库。这就是穷鬼打法。