C++怎么操作SQLite数据库_C++嵌入式数据库教程【轻便】

sqlite3_exec最简单但回调不可耗时；预编译流程更安全可控；需静态链接、最小化配置、适配内存与存储约束。

用 sqlite3_exec 执行 SQL 语句最简单，但别在回调里做耗时操作

嵌入式场景下，sqlite3_exec 是最快上手的方式，适合建表、插入单条记录、执行 DDL/DML。它把 SQL 字符串和回调函数一起扔给 SQLite，内部自动完成编译、执行、清理。

常见错误是误以为回调函数（第 4 个参数）能用来“取数据”，结果发现只调用一次、或者根本没进回调——其实是 SQL 没返回结果集（比如 INSERT 不带 RETURNING），或者传了 NULL 回调却期望拿到数据。

• 只读查询（如 select）必须提供非 NULL 回调，否则查不到结果
• 回调函数里别调用 sqlite3_exec 或其他阻塞操作，容易卡住主线程（尤其在裸机或 FreeRTOS 环境）
• 字符串参数要用 sqlite3_mprintf 或手动转义单引号，直接拼接用户输入会触发 SQL 注入

sqlite3_prepare_v2 + sqlite3_step 是安全读写的标配

需要反复执行同一条语句（比如传感器数据批量写入）、或要精确控制每一步（比如判断是否主键冲突、获取自增 ID），就得用预编译流程。它比 sqlite3_exec 多两步，但换来的是参数绑定、错误定位和资源可控。

典型坑是忘记调用 sqlite3_finalize —— 每次 prepare 都分配内存，不释放会导致句柄泄漏，在长期运行的嵌入式设备上几小时就崩。

立即学习“C++免费学习笔记（深入）”；

• 绑定参数用 sqlite3_bind_text / sqlite3_bind_int，别用 sqlite3_bind_blob 传字符串（编码易错）
• sqlite3_step 返回 SQLITE_ROW 表示有数据可读，SQLITE_DONE 表示执行完，SQLITE_BUSY 要重试（尤其多线程写时）
• 嵌入式 Flash 存储下，频繁 INSERT 建议加 BEGIN IMMEDIATE 事务，否则每次写都刷盘，寿命掉得快

编译时链接 sqlite3.o 而不是动态库，避免运行时找不到

嵌入式环境基本没有 libsqlite3.so，必须静态链接。官方源码里的 sqlite3.c 是单文件实现，直接加进工程就行，但要注意编译选项。

常见错误是开了 SQLITE_ENABLE_FTS5 或 SQLITE_ENABLE_json1 —— 这些模块在 Cortex-M3/M4 上可能吃掉几百 KB Flash，而多数传感器应用根本用不到全文检索或 JSON 解析。

• 最小化配置推荐加：-DSQLITE_THREADSAFE=0 -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_OMIT_COMPLETE
• 如果用 c++ 编译，把 sqlite3.c 加进 C 编译器（不是 C++），否则 C++ name mangling 会导致 undefined reference to sqlite3_open
• 裸机环境下，确认 malloc 已适配你的堆管理（比如用 pvPortMalloc 替换标准 malloc），SQLite 内部大量依赖它

数据库路径写成 "/data/db.sqlite" 前先检查挂载点和权限

linux/RTOS 下路径看似简单，实则最容易出 runtime 错误：目录不存在、Flash 分区只读、UID/GID 无写权限。SQLite 打开失败时返回 SQLITE_CANTOPEN，但不会告诉你具体卡在哪一层。

一个被忽略的细节是：SQLite 默认以 0600 创建文件，如果挂载时指定了 uid/gid 或用了 overlayfs，新文件可能属于 root，后续普通用户进程就打不开。

• 打开前用 access("/data", W_OK) 检查目录可写，比靠 sqlite3_open 返回值更早暴露问题
• 避免用相对路径（如 "db.sqlite"），嵌入式程序工作目录不可控，绝对路径才可靠
• 如果 Flash 寿命敏感，考虑把 WAL 日志关掉：PRAGMA journal_mode = delete，虽然并发差一点，但少一次写放大

事情说清了就结束。SQLite 在嵌入式里真正难的不是语法，而是把“磁盘 I/O”“内存分配”“并发控制”这些底层约束，揉进你对 sqlite3_step 和 sqlite3_exec 的每一次调用里。