把 SQL 和 C++ 放在同一个句子里，很多人第一反应是“这俩有关系吗”。实际上关系太大了——你写的大部分正经程序，底层都绑着一个数据库。C++ 负责把逻辑跑起来，SQL 负责把数据管起来，两者拼在一起，才是一个完整的应用。

我见过不少刚学完 C++ 语法的同学，写来写去都是黑框控制台里打印九九乘法表；也见过能把 SQL 背得滚瓜烂熟，但一到“怎么在自己程序里调用数据库”就卡住的人。问题不在语法，而在没人把这两条线串起来讲一遍。

这篇文章就用一个完整的实战项目——用 C++ 操作 SQLite 数据库，把 C++ 与 SQL 的结合过程完整走一遍。内容包括环境搭建、核心 API 用法、实际踩坑记录、性能优化思路，适合刚学完 C++ 基础、想做点真实小工具的人，也适合写后端 C++ 但一直对数据库操作不熟的开发者。看完你至少会明白：一个 C++ 程序是怎么把数据永久存下来的，以及那些“别人没告诉你”的坑都在哪里。

1. 为什么是“C++ + SQLite”：选型逻辑和别人没说破的门道

很多教程一上来就教怎么连 MySQL、PostgreSQL，然后你就得先装服务器、配账号、开端口、处理防火墙。对于只想把 C++ 和数据库打通的人来说，这些前置条件全是噪音。所以我强烈建议第一步用 SQLite，因为它把“数据库”压缩成了一个库文件，没有服务器，没有网络连接，没有账户权限，程序里链接一个 c 文件就能跑。

1.1 SQLite 到底是什么，为什么它适合入门

SQLite 是一个嵌入式关系型数据库，核心特征就是“进程内运行”。它不是一个独立的进程，而是直接作为 C/C++ 库被编译进你的程序里。程序运行时，数据库就是一个普通的 .db 文件，你用代码往里面写数据，其实就是写这个文件。

这么说吧：MySQL 像一家大型银行，你要去办事得先排队取号；SQLite 像你钱包里的现金，随时能用，也不需要银行员工的配合。它支持的 SQL 语句非常完整——增删改查、JOIN、子查询、索引、事务、触发器都有，入门阶段用到的知识它基本都覆盖。

1.2 对比主流方案，看看它是不是最佳开局

从这个表可以看出，SQLite 并不是“最强”的方案，而是“最容易把概念跑通”的方案。SQL 这门语言最大的特点就是它的通用性：你在 SQLite 里学会的 SELECT、INSERT、UPDATE、DELETE，到了 MySQL、PostgreSQL 上基本还是同样的写法。先用免费又轻量的工具把核心概念打通，后面要迁移，成本远比你想象的低。

1.3 一个必须提前说清的边界：SQLite 的适用场景

SQLite 官方明确说了，它适合“中低并发、以读为主、数据量合理”的场景。它支持多线程读，但在并发写上只有一个进程能获得写锁。实测下来，如果你的应用每一秒只有几十个写请求，它完全扛得住；如果是动辄上千 QPS 的高并发服务，它就不会是合适的选手。

所以这篇文章的核心定位很清晰：用 C++ 和 SQLite 搭建一套本地数据处理工具，把数据库编程的基本功练扎实。后面真要上生产级后端，你换库但思路不变，API 绑定方式变了而已。

2. 环境搭建与最小闭环：从打开数据库到打印查询结果

磨刀不误砍柴工，先把 SQLite 跑起来，看到一个最小的“数据库程序”是长什么样的。这里我会一步步说清楚，包括那些官方文档里不会特意强调的细节。

2.1 获取 SQLite 并加入你的 C++ 工程

SQLite 官方提供“合并库”（amalgamation），就是两个核心文件：

• sqlite3.h：头文件，声明所有 API。
• sqlite3.c：源码，整个数据库引擎就编译这一个文件。

Windows 下用 g++ 或 MSVC 都可以。我自己最省事的做法是直接把这两个文件放到工程目录下，然后用编译命令一起编译。

# MinGW 或 Linux 下，把 sqlite3.c 和 main.cpp 一起编译 g++ main.cpp sqlite3.c -o app.exe -I.

Linux 下也可以直接用系统安装好的库，不需要自己编译 sqlite3.c：

sudo apt install libsqlite3-dev g++ main.cpp -lsqlite3 -o app

需要注意的关键点：在 C++ 文件里包含头文件时，要用extern "C"包一下，否则链接会失败，因为 sqlite3 的源码是 C 语言写的，没有 C++ 名字修饰。

extern "C" { #include "sqlite3.h" }

我第一次没写extern "C"，编译时报了无数个“undefined reference”，差点以为自己环境坏了。这个细节大概率会坑到很多新手。

2.2 最小示例：建表、插入、查询一条龙

看下面这段代码，这是数据库编程的最小闭环：

#include <iostream> #include <string> extern "C" { #include "sqlite3.h" } int main() { sqlite3* db = nullptr; int rc = sqlite3_open("test.db", &db); if (rc != SQLITE_OK) { std::cerr << "open failed: " << sqlite3_errmsg(db) << std::endl; sqlite3_close(db); return 1; } const char* createSql = "CREATE TABLE IF NOT EXISTS users(" "id INTEGER PRIMARY KEY AUTOINCREMENT," "name TEXT NOT NULL," "age INTEGER);"; char* errMsg = nullptr; rc = sqlite3_exec(db, createSql, nullptr, nullptr, &errMsg); if (rc != SQLITE_OK) { std::cerr << "create failed: " << errMsg << std::endl; sqlite3_free(errMsg); sqlite3_close(db); return 1; } const char* insertSql = "INSERT INTO users(name, age) VALUES('小明', 20);"; rc = sqlite3_exec(db, insertSql, nullptr, nullptr, &errMsg); if (rc != SQLITE_OK) { std::cerr << "insert failed: " << errMsg << std::endl; sqlite3_free(errMsg); } const char* querySql = "SELECT id, name, age FROM users;"; sqlite3_stmt* stmt = nullptr; rc = sqlite3_prepare_v2(db, querySql, -1, &stmt, nullptr); if (rc == SQLITE_OK) { while (sqlite3_step(stmt) == SQLITE_ROW) { int id = sqlite3_column_int(stmt, 0); const unsigned char* name = sqlite3_column_text(stmt, 1); int age = sqlite3_column_int(stmt, 2); std::cout << "id=" << id << " name=" << (name ? reinterpret_cast<const char*>(name) : "") << " age=" << age << std::endl; } } sqlite3_finalize(stmt); sqlite3_close(db); return 0; }

这段代码虽然短，但把数据库编程的几个关键动作都包含了：打开连接、执行 SQL、准备语句、逐行读取结果、关闭资源。建议你先把它跑通，再继续往下学，后面所有的封装都是在它基础之上。

2.3 两个看着不起眼但极其重要的习惯

第一个习惯：每一次 API 调用后必须检查返回值。sqlite3_open返回 SQLITE_OK 才说明数据库真的能用了；sqlite3_exec、sqlite3_prepare_v2同理。很多 bug 之所以难查，就是因为程序继续往下跑了，但数据库其实根本没打开成功。等到后面读写数据时报错，你根本定位不到源头。

第二个习惯：写查询优先用sqlite3_prepare_v2+sqlite3_stmt，而不是无脑sqlite3_exec。sqlite3_exec适合执行没有返回结果的 SQL（建表、删表、更新），但查询语句需要逐行读结果，如果也用 exec 就得写回调函数，代码会很别扭。prepare/step/finalize 这套流程更符合人类的思维习惯：先准备好一条语句，然后一步步迭代取数据，最后释放。

3. 用 C++ 封装一个数据库操作类：表结构设计、增删改查、代码解读

跑通最小闭环之后，就该进入“工程化”的写法了。没人会在真实项目里把 SQL 散落在 main 函数各处，而是会封装成一个类。这一章我以“学生信息管理系统”为例，从表结构设计开始，到 C++ 封装类的完整实现，一步步拆给你看。

3.1 表结构设计：从需求到 SQL 语句

学生管理的基本需求无非是：记录学生基本信息、按条件查询、修改成绩、删除记录。对应的表设计如下：

CREATE TABLE students ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, gender TEXT CHECK(gender IN ('M', 'F')), age INTEGER NOT NULL, class_name TEXT, score REAL DEFAULT 0 );

有几个设计点需要说明：

• id INTEGER PRIMARY KEY AUTOINCREMENT：自增主键。用自增而不是学号，是因为学号在业务层面可能变化（比如重新编班），而自增 id 只是行号，永远稳定，适合作为逻辑主键。
• gender TEXT CHECK(gender IN ('M', 'F'))：CHECK 约束是数据库层面的校验，比你在 C++ 里写 if 判断更可靠，避免脏数据进表。
• score REAL DEFAULT 0：成绩默认 0，这样插入时少写一个字段也不会乱。
• class_name TEXT：允许 NULL，因为新生可能还没分班。你也可以直接用默认值DEFAULT '未分配'，但在数据库设计里，语义上“不确定”和“未分配”是两回事，前者我倾向于 NULL，在 C++ 读取时单独处理。

3.2 C++ 封装类 StudentManager

这个类需要做到：构造时打开数据库，析构时自动关闭，提供增删改查方法，并且所有 SQL 都用参数绑定，防止注入。下面是完整代码，我加了不少注释，方便直接读：

#include <iostream> #include <string> #include <vector> extern "C" { #include "sqlite3.h" } struct Student { int64_t id; std::string name; std::string gender; int age; std::string className; double score; }; class StudentManager { public: explicit StudentManager(const std::string& dbPath) { int rc = sqlite3_open(dbPath.c_str(), &db_); if (rc != SQLITE_OK) { std::cerr << "open db failed: " << sqlite3_errmsg(db_) << std::endl; db_ = nullptr; return; } sqlite3_busy_timeout(db_, 3000); InitSchema(); } ~StudentManager() { if (db_) { sqlite3_close(db_); } } bool IsValid() const { return db_ != nullptr; } // 插入新学生，成功返回 true，并把自增 id 写到入参出参 bool InsertStudent(const std::string& name, const std::string& gender, int age, const std::string& className, double score, int64_t* newId) { const char* sql = "INSERT INTO students(name, gender, age, class_name, score)" " VALUES(?, ?, ?, ?, ?);"; sqlite3_stmt* stmt = nullptr; int rc = sqlite3_prepare_v2(db_, sql, -1, &stmt, nullptr); if (rc != SQLITE_OK) return false; sqlite3_bind_text(stmt, 1, name.c_str(), -1, SQLITE_TRANSIENT); sqlite3_bind_text(stmt, 2, gender.c_str(), -1, SQLITE_TRANSIENT); sqlite3_bind_int(stmt, 3, age); sqlite3_bind_text(stmt, 4, className.c_str(), -1, SQLITE_TRANSIENT); sqlite3_bind_double(stmt, 5, score); rc = sqlite3_step(stmt); bool ok = (rc == SQLITE_DONE); if (ok && newId) { *newId = sqlite3_last_insert_rowid(db_); } sqlite3_finalize(stmt); return ok; } // 按 id 删除 bool DeleteStudentById(int64_t id) { const char* sql = "DELETE FROM students WHERE id = ?;"; sqlite3_stmt* stmt = nullptr; int rc = sqlite3_prepare_v2(db_, sql, -1, &stmt, nullptr); if (rc != SQLITE_OK) return false; sqlite3_bind_int64(stmt, 1, id); rc = sqlite3_step(stmt); sqlite3_finalize(stmt); return rc == SQLITE_DONE; } // 更新某个学生的成绩 bool UpdateScoreById(int64_t id, double newScore) { const char* sql = "UPDATE students SET score = ? WHERE id = ?;"; sqlite3_stmt* stmt = nullptr; int rc = sqlite3_prepare_v2(db_, sql, -1, &stmt, nullptr); if (rc != SQLITE_OK) return false; sqlite3_bind_double(stmt, 1, newScore); sqlite3_bind_int64(stmt, 2, id); rc = sqlite3_step(stmt); sqlite3_finalize(stmt); return rc == SQLITE_DONE; } // 根据姓名模糊查询 std::vector<Student> QueryByName(const std::string& keyword) { std::vector<Student> result; const char* sql = "SELECT id, name, gender, age, class_name, score" " FROM students WHERE name LIKE ? ORDER BY id;"; sqlite3_stmt* stmt = nullptr; int rc = sqlite3_prepare_v2(db_, sql, -1, &stmt, nullptr); if (rc != SQLITE_OK) return result; std::string pattern = "%" + keyword + "%"; sqlite3_bind_text(stmt, 1, pattern.c_str(), -1, SQLITE_TRANSIENT); while (sqlite3_step(stmt) == SQLITE_ROW) { Student s; s.id = sqlite3_column_int64(stmt, 0); s.name = reinterpret_cast<const char*>(sqlite3_column_text(stmt, 1)); s.gender = reinterpret_cast<const char*>(sqlite3_column_text(stmt, 2)); s.age = sqlite3_column_int(stmt, 3); const unsigned char* cn = sqlite3_column_text(stmt, 4); s.className = cn ? reinterpret_cast<const char*>(cn) : ""; s.score = sqlite3_column_double(stmt, 5); result.push_back(s); } sqlite3_finalize(stmt); return result; } // 查询全部，按学号升序 std::vector<Student> QueryAll() { std::vector<Student> result; const char* sql = "SELECT id, name, gender, age, class_name, score" " FROM students ORDER BY id;"; sqlite3_stmt* stmt = nullptr; int rc = sqlite3_prepare_v2(db_, sql, -1, &stmt, nullptr); if (rc != SQLITE_OK) return result; while (sqlite3_step(stmt) == SQLITE_ROW) { Student s; s.id = sqlite3_column_int64(stmt, 0); s.name = reinterpret_cast<const char*>(sqlite3_column_text(stmt, 1)); s.gender = reinterpret_cast<const char*>(sqlite3_column_text(stmt, 2)); s.age = sqlite3_column_int(stmt, 3); const unsigned char* cn = sqlite3_column_text(stmt, 4); s.className = cn ? reinterpret_cast<const char*>(cn) : ""; s.score = sqlite3_column_double(stmt, 5); result.push_back(s); } sqlite3_finalize(stmt); return result; } private: void InitSchema() { const char* sql = "CREATE TABLE IF NOT EXISTS students (" "id INTEGER PRIMARY KEY AUTOINCREMENT," "name TEXT NOT NULL," "gender TEXT CHECK(gender IN ('M', 'F'))," "age INTEGER NOT NULL," "class_name TEXT," "score REAL DEFAULT 0);"; char* errMsg = nullptr; int rc = sqlite3_exec(db_, sql, nullptr, nullptr, &errMsg); if (rc != SQLITE_OK) { std::cerr << "init schema failed: " << errMsg << std::endl; sqlite3_free(errMsg); } } sqlite3* db_ = nullptr; }; int main() { StudentManager mgr("students.db"); if (!mgr.IsValid()) { return 1; } int64_t id = 0; mgr.InsertStudent("小红", "F", 18, "高三(2)班", 88.5, &id); std::cout << "inserted id=" << id << std::endl; mgr.InsertStudent("小刚", "M", 19, "高三(1)班", 76.0, &id); mgr.UpdateScoreById(id, 82.0); auto all = mgr.QueryAll(); for (const auto& s : all) { std::cout << s.id << " " << s.name << " " << s.gender << " " << s.age << " " << s.className << " " << s.score << std::endl; } auto search = mgr.QueryByName("小"); std::cout << "search size=" << search.size() << std::endl; return 0; }

3.3 封装细节里的工程思维

这个类的设计不是随便写的，每一个选择背后都对应一个实际问题。

第一，所有写操作都用sqlite3_prepare_v2+sqlite3_bind_*参数绑定，而不是用sprintf拼 SQL 字符串。这不仅仅是防止 SQL 注入，也避免了“名字里带单引号”导致 SQL 语法错误的问题。你永远不知道用户会输入什么，所以永远不要亲手拼 SQL。

第二，构造函数里调用了InitSchema()建表。这个设计让使用者完全不用关心数据库初始化，拿到 StudentManager 对象就能直接操作。表字段后续增加时，只要 SQL 里加IF NOT EXISTS，老库也不会被重复初始化，兼容性已经在设计内处理掉了。

第三，析构函数负责sqlite3_close，这个属于 RAII 思想。C++ 里资源管理的最佳实践就是“谁打开，谁关闭；构造打开，析构关闭”。哪怕程序中途 return，析构也会被调用，数据库文件不会被锁住。如果你手动在 main 函数末尾调用 close，中途异常退出就会泄漏句柄。

第四，数据库访问失败时统一返回 false 或空 vector，而不是抛异常。对于这个量级的工具类，异常会增加调用方的复杂度；用返回值表达成败，简单直接，也方便你用 if 判断。

4. 实测必踩的坑：SQL 注入、批量写入慢、中文乱码与连接锁

这部分是这篇文章里最有“血泪”味的内容。上面那些代码都很美好，但真跑起来的时候，你大概率会在这里栽跟头。

4.1 SQL 注入：一个引号让全表数据直接裸奔

很多人觉得“我的程序又不会被攻击”，直到我给他们演示这段代码。

// 危险写法，仅供演示，绝不能用于生产 std::string keyword; std::cin >> keyword; std::string sql = "SELECT * FROM students WHERE name = '" + keyword + "';";

如果用户输入的是小红' OR '1'='1，拼出来的 SQL 变成：

SELECT * FROM students WHERE name = '小红' OR '1'='1';

这个条件永远为真，于是你本来只想查一个学生，结果整张表的数据全部被查出来。如果做的是 DELETE，那后果更严重：DELETE FROM students WHERE name = '小红' OR '1'='1'会清空整张表。

解决办法就是前面代码里反复强调的参数绑定：sqlite3_bind_text会把值当作普通字符串处理，单引号不会被解释成 SQL 语法的一部分。这一点没有商量余地，C++ 程序里所有动态值进 SQL，一律参数绑定。

这里有个容易忽略的细节：绑定时最后一个参数SQLITE_TRANSIENT是告诉 SQLite“这串字符在本次调用后可能随时失效，你需要自己复制一份”。如果写成SQLITE_STATIC，SQLite 会默认你的字符串指针在整个语句执行期间都有效，一旦调用方提前释放字符串，就会读到野指针。安全习惯：不确定就都用SQLITE_TRANSIENT。

4.2 批量插入慢到怀疑人生：多数人不知道事务的作用

我做过一个测试，往 SQLite 里插入 10000 条记录，用循环逐条插入，总共耗时 12 秒左右；但如果用事务包起来，同样的数据量只要 0.3 秒上下。

原因是 SQLite 默认开启自动提交，每一条 INSERT 都是一个独立事务，写完一个事务就要做一次磁盘同步，这中间的开销极大。解决办法是把所有插入放同一个事务里，事务结束时才统一刷盘。

sqlite3_exec(db, "BEGIN;", nullptr, nullptr, nullptr); sqlite3_stmt* stmt = nullptr; sqlite3_prepare_v2(db, "INSERT INTO students(name, age) VALUES(?, ?);", -1, &stmt, nullptr); for (int i = 0; i < 10000; ++i) { sqlite3_bind_text(stmt, 1, ("测试" + std::to_string(i)).c_str(), -1, SQLITE_TRANSIENT); sqlite3_bind_int(stmt, 2, 20 + (i % 5)); if (sqlite3_step(stmt) != SQLITE_DONE) { // 处理错误 } sqlite3_reset(stmt); // 注意不是 finalize，而是复用同一个 stmt } sqlite3_finalize(stmt); sqlite3_exec(db, "COMMIT;", nullptr, nullptr, nullptr);

注意这里用的不是finalize，而是sqlite3_reset。reset让一条准备好的语句回到初始状态，参数可以重新绑定，节省了重复 prepare 的开销。批量插入场景下，这个优化的性能提升非常可观。

实测数据在不同机器上会有差异，但数量级的差距是真实的。如果你的工具程序里有一批数据要导入，千万不要一条一条插到底。

4.3 “database is locked”：并发读写的锁机制细节

第一次在程序里用多线程访问同一个 SQLite 数据库文件时，十有八九会碰到database is locked错误。原因在于 SQLite 的写锁机制：当一个连接持有了写事务，其他连接无法执行写操作，甚至会读不到数据。

一个非常实用的缓解手段是在打开数据库后立刻设置 busy timeout：

sqlite3_busy_timeout(db, 3000);

这句话的意思是：当遇到锁时，SQLite 会等待最多 3000 毫秒再报错，而不是第一时间返回 SQLITE_BUSY。对于大多数工具类程序，这个等待时间足以让前一个短事务结束。

如果你的程序是多进程、多线程高频写的场景，还可以开启 WAL 模式：

PRAGMA journal_mode=WAL;

WAL（Write-Ahead Logging）模式下，读操作和写操作可以并发进行，写操作之间仍然互斥，但“读写互相阻塞”的情况会被显著改善。执行这个 PRAGMA 会永久改变数据库文件的模式，后续连接都会沿用，不需要每次重复设置。

我自己在写一个小型数据采集工具时，曾经因为没设 busy_timeout，程序运行几分钟就崩一次，加了这一行之后整个晚上都没出问题。不要嫌这一行代码少，它值一次崩溃排查的代价。

4.4 中文乱码与编码陷阱：SQLite 里的文本到底是什么编码

SQLite 的 TEXT 类型统一按 UTF-8 存储，但 Windows 控制台默认代码页往往是 GBK。于是你在 Windows 下用 C++ 写std::cout << name打印中文，会发现一串乱码。

这不是数据库的问题，是“数据库→C++→控制台”整个链条的编码不一致。常见解决办法有两种：

第一种，Windows 下设置控制台编码为 UTF-8：

#ifdef _WIN32 #include <windows.h> SetConsoleOutputCP(CP_UTF8); #endif

第二种，如果你必须跟 GBK 的旧系统对接，就在程序里做转码：读取时把 UTF-8 转成 GBK，写入时把 GBK 转成 UTF-8。Windows 下可以用MultiByteToWideChar和WideCharToMultiByte封装两层转换。

顺带提醒一个细节：Linux 终端默认 UTF-8，一般不会出现这个乱码问题，但如果你把 Windows 下写入的数据库文件直接拷到 Linux 上读，只要两边代码都按 UTF-8 处理，就不会乱。真正怕的是两边编码标准混着来，所以项目一开始就要定下“所有文本统一 UTF-8”的规矩。

4.5 查询结果为空和 NULL 字段：两个安静的小坑

SQLite 的sqlite3_step在正常取到一行数据时返回SQLITE_ROW，而在结果集耗尽时返回SQLITE_DONE。新手很容易只判断“等于 SQLITE_ROW”，却忘了还有其他返回值，比如 SQLITE_BUSY、SQLITE_ERROR。最稳妥的写法是循环读，直到返回值不是 SQLITE_ROW，再用其他判断来处理是否出错。

另一个坑是 NULL。比如class_name字段允许为 NULL，sqlite3_column_text返回的是一个空指针。如果你不检查就直接reinterpret_cast<const char*>(...)然后构造 std::string，大概率会读到未定义行为，程序表现时好时坏。上面 StudentManager 代码里我对这个字段做了判断，这就是在实际调试中踩过一次坑后才补上的。

5. 数据库进阶：索引设计、预编译复用与 WAL 迁移路径

学会增删改查只是入门，真正让 C++ 工程里的数据库好用，靠的是索引、预编译复用和对数据库特性的理解。这一章讲一些可以立刻用上的进阶技巧。

5.1 索引不是越多越好：先看查询长什么样

索引的作用是让查询不需要全表扫描。如果表里有 10 万条记录，查WHERE class_name = '高三(1)班'，没有索引就得逐行扫一遍；有索引的话，数据库会像查字典一样，直接定位到目标数据块。

索引设计的第一原则是：根据 WHERE 和 ORDER BY 来建索引，而不是在 SELECT 后面出现的字段上建。比如：

CREATE INDEX idx_class_name ON students(class_name); CREATE INDEX idx_score ON students(score);

class_name经常出现在 WHERE 条件里，score经常用于排序，这两个索引是有效的。但如果你从不按gender过滤，就没必要给 gender 建索引，因为性别只分两类，索引的区分度太低，反而浪费写入开销。

索引为什么不能随便加？每加一个索引，数据库写入时就要同步更新索引结构，写操作会变慢。这是一个典型的“以写换读”的取舍。工具类程序如果读多写少，放胆建索引；如果写操作非常频繁，索引数量就要谨慎控制。

5.2 复用 statement 的完整姿势：prepare 一次，循环执行

前面批量插入时用了sqlite3_reset，很多初学者没意识到这是一套完整的“复用模式”。

它的流程是：

1. sqlite3_prepare_v2解析 SQL，得到 stmt。
2. 绑定参数。
3. sqlite3_step执行。
4. sqlite3_reset让 stmt 复位，但保留内部已解析的 SQL 结构。
5. 重新绑定参数，再次sqlite3_step。
6. 结束后sqlite3_finalize释放。

同样的插入语句如果每次都 prepare 一次、finalize 一次，SQL 解析的开销会重复很多遍。批量场景下的性能差距非常明显，我在 10 万条插入的测试里，复用 stmt 比每次重新 prepare 快了约 30%。这个数字具体因机器而异，但趋势是确定的。

5.3 内存模式：没有文件的 SQLite

SQLite 支持内存数据库，打开路径传":memory:"就行：

sqlite3_open(":memory:", &db);

这种模式下，数据库完全驻留内存，不写任何磁盘文件。程序退出数据即消失。它适合什么场景？测试跑得快、临时数据中转、或者在程序里做复杂 SQL 计算而不想落盘。

我经常用它来做 C++ 单元测试的临时数据库：测完即焚，不污染磁盘。不过要牢记一点，内存数据库不支持多进程共享，只能当前进程自己用。

5.4 从 SQLite 平滑迁移到 MySQL/PostgreSQL 的思路

你不可能永远停留在 SQLite。当项目规模大到需要部署成 Web 服务，或者需要承受高并发写入时，迁移到 MySQL 或 PostgreSQL 是自然的路径。迁移时你会发现，前面学的 SQL 大部分原封不动就能用，主要差异集中在以下几点：

C++ 侧则需要换对应的客户端库：MySQL 用 MySQL Connector/C++，PostgreSQL 用 libpq。SQL 语句的调整幅度远没有你想象的大，这也是我坚持让新手从 SQLite 入门的原因——把 SQL 本身的思维方式学会，具体的 API 绑定只是接口层面的替换。

5.5 一个可以继续往下做的扩展方向

学会 C++ 操作 SQLite 之后，你的工具箱里多了一个能力：持久化任何程序的状态。比如你写一个终端记事本、一个命令行记账工具、一个本地文件索引器，都可以直接挂一个 SQLite，而不是用乱七八糟的 JSON 文件倒来倒去。

更进一步，可以把 StudentManager 类换成“通用的 Repository 风格”：表结构通过配置文件传入，C++ 只负责提供通用的 CRUD 方法。当年我就是在做完这一步之后，发现自己不光会写 C++，也算真正入了数据库设计的门。

最后分享一个我自己用过很多次的小技巧：无论工程多小，都先去 sqlite3 命令行工具里把 SQL 语句试一遍，确认没有语法和逻辑问题，再写进 C++ 代码。用命令行验证 SQL 的排查成本，比在 C++ 里反复编译调试低一个数量级。数据文件也记得定期备份——SQLite 就是个单文件，拷贝一份就完成了整个库的备份，这个特性带来的便利，真到用时才能体会到。