workerd 把 SQLite 操作上限从 25000 提到 250000：什么时候会撞上

Cloudflare 的 workerd 发布了 v1.20261029.1，改动列表里有一条很不起眼但值得关注：把 SQLITE_LIMIT_VDBE_OP 从 25000 提到 250000。

这个参数是什么

SQLite 的 VDBE 是它的虚拟机，一条 SQL 会被编译成一串虚拟机指令。VDBE_OP 限制的是单条语句可以执行的指令数，本质是防止一条查询把 CPU 吃光的保护性上限。默认值 25000 对普通 OLTP 查询绰绰有余，但在两种情况下会撞墙：一是带复杂子查询或大量 OR 条件的分析型 SQL，二是需要排序大量行的语句，因为排序会展开成大量指令。

为什么提到 250000

在 Durable Objects 或 Workers 里跑 SQLite 的场景在变重。原来只是存一点状态，现在有人在里面跑聚合、算报表、做全文检索。上限太低的表现是 statement too large 或直接超限报错，而且报错信息不够直白，容易被误判成数据量问题。提高十倍等于把这条隐形的墙往后推。

代价要清楚

上限提高意味着单条语句可能占用更多 CPU 时间。在按 CPU 计费、有执行时限的运行时里，这会把「查询被拦」换成了「查询超时」。所以提高上限不是免费的，实际写法上仍然应该：把大聚合拆成多条小查询、给排序字段建索引、能靠索引范围扫描就别全表排序。

同一版本里另外两条值得看的修复

formData() 在配合 TypeScript streams 时会损坏二进制分段，现在修了；还有一条是 TypeScript stream 的 pump 被丢弃时，排队中的流要正确取消。这两个都跟 Web 标准 API 在 Workers 里的实现细节有关，做文件上传和流式代理的人受影响最直接。另外 Temporal 现在与 Date.now() 使用同一时间源，行为更一致。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

上限提高换来的是查询超时，在按 CPU 计费又有执行时限的运行时里，这堵墙只是挪了位置。大聚合还是得拆小查询，排序字段该建索引就建，别指望上限兜底。

上限从 25000 提到 250000 解决的是长语句，不是慢查询。真正会撞的场景是递归 CTE 加多层子查询拼出来的报表 SQL，指令数翻着涨。但提高十倍也意味着一条坏 SQL 能把 CPU 吃得更久，边缘节点更该配超时和结果行数限制，光靠这个保护上限已经不够了。

25000 提到 250000 看着是个小改动，实际是把一道保护性闸门往上抬了一个数量级。以前撞上限说明查询本身写得有问题，现在能跑过去了，问题变成慢查询悄悄吃 CPU。我们的经验是保留原值加监控，看到 VDBE 指令数异常再排查，别直接把上限放开当优化。