CF-Server-Monitor 紧急升级修复：解决 D1 索引 Bug引发的额度爆表问题
🚨 紧急提醒：CF-Server-Monitor 用户请尽快升级
CF-Server-Monitor 探针 Bug 修复提示界面
最近在用 CF-Server-Monitor 监控服务器的小伙伴注意了，如果你升级到了 V2.7.0 版本，可能会遇到一个比较棘手的 Bug，这可能会直接导致你的 Cloudflare D1 读取额度（Read Units）异常飙升，甚至爆表。
为了大家的钱包和监控稳定性，建议立刻进行一次升级操作。下面我带大家详细看看这次的问题是咋回事，以及如何无痛修复。
🐛 Bug 起因：想省钱反而费流量
在 V2.7.0 版本中，开发者为了优化 Cloudflare D1 的存储成本，加入了一个看似很完美的“懒人清理”机制：
由于在 D1 中直接删除历史记录是按行收费的（每删一条都要扣一个写入配额），这显然不划算。于是新版本设计了一个“月度轮转”策略：
- 每月定时将
metrics_history表重命名为metrics_history_old。 - 然后新建一个空的
metrics_history表继续写入数据。 - 8天后，系统再自动删除旧的
_old表。
这个逻辑原本的目的是实现清理数据的“0消耗”。但是，现实骨感，这里出现了一个严重的逻辑漏洞。
Cloudflare D1 控制台展示数据库读写额度与索引状态
⚠️ 问题核心：索引“跟错了人”
问题出在数据库的索引处理上。
当你重命名 metrics_history 表时，原本属于该表的索引 ID 并没有留在原地，而是傻乎乎地跟着表名一起跑到了 metrics_history_old 中。
紧接着，当系统创建新的 metrics_history 表时，试图添加索引。这时候，由于旧索引 ID 还在“老表”里被占用，新表添加索引就会因为 ID 重复而失败。
后果是什么？
- 新表没有索引，查询性能极差，甚至导致全表扫描。
- 最致命的是，这种低效查询会疯狂消耗 D1 的读取行额度。
- 这就是为什么很多人发现自己明明没怎么操作，读额度却直接爆表的原因。
✅ 解决方案：自动修复，一键同步
好消息是，开发者已经修复了这个 Bug。新版本会在访问首页时自动检测并补全缺失的索引。你需要做的非常简单，只需要让代码更新即可。
🛠️ 手把手升级教程
因为你使用的是 Fork 到自己账号下的项目，所以同步上游代码是必须的步骤。操作如下：
- 打开你的 GitHub：进入你自己 Fork 后的 CF-Server-Monitor 项目地址。
- 点击 Sync fork：在项目页面上方通常会有一个绿色的“Sync fork”按钮。
- Update branch：点击后选择“Update branch”，将上游的最新修复代码合并到你的分支中。
- 此时，Cloudflare Workers 会自动检测到代码变更，并触发自动重新部署，无需你手动操作。
❓如果我修改过代码怎么办？
如果你之前为了魔改功能修改过文件，同步时可能会遇到冲突。
- 最佳实践：如果修改不重要，建议点击
Discard commits（放弃提交），先让代码回滚干净，再进行 Sync 同步。 - 如果必须要保留修改：你需要手动解决冲突后再部署，但这涉及到一定的代码基础，小白建议直接回退。
💡 总结与建议
这个 Bug 虽然坑人，但也提醒我们在使用 Serverless 数据库（特别是像 D1 这种有额度限制的）时，索引管理的重要性。
- 检查额度：升级后，记得去 Cloudflare 控制台看看 D1 的读写情况是否恢复正常。
- 保持更新：对于这种探针类工具，紧跟上游版本通常是避免“踩雷”最有效的方法。
赶紧去 GitHub 点一下同步吧，别让这一个 Bug 偷走了你的额度！
项目地址：CF-Server-Monitor (GitHub 搜索即可) 如果遇到问题，也可以通过官方 TG 群反馈。
评论已关闭