【SQLite 内核】VDBE 字节码执行：prepare、step 与寄存器机
内容提要
本文介绍SQLite的VDBE字节码执行引擎。sqlite3_prepare_v2将SQL编译为字节码程序，sqlite3_step在虚拟机上执行该程序。通过EXPLAIN分析点查SELECT name FROM t WHERE id=1，展示Transaction→OpenRead→SeekRowid→Column→ResultRow的执行流程。VDBE通过游标调用B-Tree，不直接读文件。强调opcode细节非稳定API，升级后需重新验证。
延伸解读
理解 prepare 与 step 的分工
sqlite3_prepare_v2 将 SQL 编译为字节码，而 sqlite3_step 只是执行该程序。这意味着重复执行同一语句时，应复用 prepared statement 或使用参数绑定，而不是每次重新解析。理解这一分工有助于优化应用性能，避免不必要的编译开销。
EXPLAIN 输出的版本敏感性
文章强调 opcode 细节并非稳定 API，会随 SQLite 版本变化。因此，依赖 EXPLAIN 输出进行业务逻辑或工具开发存在风险，升级 SQLite 后可能导致静默失败。建议在固定版本下进行调试，并对照同版本的官方文档或源码注释。
VDBE 与 B-Tree 的协作机制
VDBE 通过游标调用 B-Tree，而非直接读取文件。例如，SeekRowid 定位主键，Column 解出列值，最终通过 ResultRow 返回。这种分层设计将执行与页面 I/O 分离，有助于理解 SQLite 的架构和性能特征。
Q&A
SQLite中sqlite3_prepare_v2和sqlite3_step分别负责什么？
sqlite3_prepare_v2将SQL文本编译成字节码程序（prepared statement），sqlite3_step在虚拟机上执行该程序，每次调用推进执行，返回一行结果（SQLITE_ROW）或完成（SQLITE_DONE）。
SQLite的VDBE是什么？为什么使用字节码而不是直接执行解析树？
VDBE（Virtual DataBase Engine）是SQLite的字节码执行引擎，prepared statement本质上就是实现SQL的字节码。使用字节码的原因包括：便于可移植、便于用EXPLAIN观测、便于在一条语句内表达分支和子程序。
SQLite的EXPLAIN输出是稳定的API吗？可以依赖它吗？
不是。官方明确说明opcode细节随版本变化，不是稳定API，应用不得依赖细节。升级SQLite版本后，EXPLAIN输出可能变化，需要重新验证。
在SQLite中，一次点查（SELECT name FROM t WHERE id=1）的VDBE执行流程是怎样的？
以SQLite 3.53.2为例，EXPLAIN显示有效执行顺序为：Transaction（进入读事务）→ OpenRead（打开表t的游标，根页为2）→ Integer（将id值1存入寄存器r[1]）→ SeekRowid（按整数key定位）→ Column（取出name列到r[2]）→ ResultRow（输出r[2]并返回SQLITE_ROW）。
SQLite的VDBE如何与B-Tree交互？它直接读取数据库文件吗？
VDBE通过游标（cursor）调用B-Tree API，不直接读取文件。例如OpenRead打开游标并绑定根页，SeekRowid在游标上定位，Column解出列值。B-Tree再通过Pager访问页面，最终由Pager负责文件I/O。
SQLite的寄存器是什么？与CPU寄存器有何不同？
SQLite的寄存器是虚拟机寄存器文件，是一组固定数量的槽，每个槽可以持有NULL、整数、浮点、文本、BLOB等类型。它不是CPU寄存器，而是虚拟机内部的数据存储。
EXPLAIN和EXPLAIN QUERY PLAN有什么区别？
EXPLAIN输出VDBE指令列表，是底层字节码；EXPLAIN QUERY PLAN输出高层访问路径（如是否使用索引）。排查计划问题时应优先使用EXPLAIN QUERY PLAN。
SQLite的VDBE执行中，ResultRow指令的作用是什么？
ResultRow指令将当前行的列值（已装入寄存器）输出，使sqlite3_step返回SQLITE_ROW并暂停虚拟机；下一次调用step时从下一条指令继续执行。
