五微秒 JIT 让数据库每条 SQL 都能即时编译，AI 降低的是汇编实现门槛
pgrust 作者 Jason Malis 公开了其快速 JIT 编译器的实现思路：通过 copy-and-patch 模板直接生成 ARM64 机器码，把编译时间压到约 5 微秒，因此数据库可以尝试对每条 SQL 查询即时编译，而不只挑选长查询。
林岚
pgrust 作者 Jason Malis 公开了其快速 JIT 编译器的实现思路：通过 copy-and-patch 模板直接生成 ARM64 机器码，把编译时间压到约 5 微秒，因此数据库可以尝试对每条 SQL 查询即时编译，而不只挑选长查询。
一句话结论：AI 没有发明 JIT，但它让一个不以汇编见长的开发者也能实现、检查和迭代机器码模板，从而把过去不划算的专用编译器变成可尝试的工程选项。
传统数据库若要 JIT，常借助 LLVM 或先生成 C/C++ 再调用编译器。这些方案成熟，却有较高启动成本；如果编译耗时比查询本身还长，只有复杂、重复运行的语句值得编译。pgrust 的目标是把门槛压到足够低，让短查询也能从运行时信息中受益。
文章用只支持字面量和 * 重复的玩具正则引擎解释方案。解释器实现不到 20 行，但在测试中比针对表达式手写的代码慢 10 至 20 倍。JIT 先为字符比较、分支、循环、匹配和失败逻辑准备机器码 stencil，再根据正则 AST 填入字符与跳转偏移，最后把片段拼成可执行函数。
生成代码后，程序用 mmap 分配内存、写入指令，并遵守 macOS ARM64 的写入/执行保护切换。最终测试里，JIT 与手写实现大体相当，有些输入快一点，有些慢一点。这个结果只针对简化正则和特定机器，不能直接推导完整 SQL 引擎也有同样倍数。
此前 OC 已讨论 Coding Agent 让大量小优化变得便宜；这次的新信息是一个具体边界：当代码本身高度机械、可用测试和反汇编验证时，Agent 对汇编生成尤其有帮助。真正危险的部分仍是可执行内存、分支偏移、ABI 和正确性验证，不能靠“编译成功”放行。
五微秒真正改变的不是单次基准，而是数据库优化器可以考虑的决策空间。编译成本足够低后，系统可以结合本次查询的常量、列类型和分支概率生成更专用的路径，甚至在低复用查询上尝试 JIT。但这也会带来代码缓存膨胀、指令缓存压力和编译风暴等新问题；生产系统必须设定预算、回退到解释执行，并把生成代码纳入模糊测试与差分测试。
关键事实
- 项目：Rust 数据库 pgrust 的专用 JIT。
- 编译时间：作者报告约 5 微秒。
- 方法：copy-and-patch，把预制 ARM64 stencil 填充后拼接。
- 示例结果：简化正则 JIT 性能与手写实现大致相当。
OC 判断
AI 最适合压低那些“规则明确、实现烦琐、反馈可执行”的工程成本，汇编模板正属于这一类。但数据库 JIT 的生产价值还要看查询分布、代码缓存、跨架构支持和错误隔离，不能从玩具正则直接跳到全面胜利。
为什么重要
- 对数据库开发者：编译启动成本下降会改变解释与编译的分界线。
- 对系统程序员：Agent 可以辅助机器码实现，但验证体系必须先存在。
- 对用户：收益最终应体现为尾延迟和吞吐，而不是编译器本身的漂亮数字。
评论
围绕这篇文章补充信息、提出问题或分享观察。