企业官网建设流程全解析

1. 先搞清楚：SQLite到底解决了什么问题，以及它的“轻量”为什么是护城河

做本地开发这些年，我见过太多项目在“要不要上数据库”这件事上来回纠结。后端说“这功能就一个客户端用，上MySQL太浪费”，前端说“那就存JSON文件吧，简单”，结果数据一多，查询、排序、去重、事务全部要靠手写代码硬扛，维护成本直线上升。这时候SQLite这个名字就会反复出现——它是目前部署量最大的数据库引擎，没有之一，手机、PC浏览器、路由器、车载系统、收银机里几乎都有它的影子。但很多人对它的认知停留在“一个轻量级数据库”，具体轻在哪、适合干什么、不适合干什么，其实并没有想清楚。

我自己的定位很明确：SQLite就是本地存储场景的首选关系型数据库。它不需要独立服务进程，不需要端口配置，不需要账号密码，数据就是一个文件，把这个文件拷走，数据就跟着走了。对于个人工具、移动App、桌面应用、边缘计算设备这些不需要多人并发写入的场景，SQLite在开发效率和查询能力上的综合性价比，远高于MySQL之类的大型数据库，也远高于自己用JSON、CSV硬写一套“伪数据库”。

1.1 嵌入式数据库和C/S数据库不在一个赛道

碰到SQLite，最容易犯的错误是拿它去跟MySQL、PostgreSQL对比，然后得出“高端数据库更强”的结论。这个结论单独看没错，但放在本地存储这个上下文里基本没有意义。SQLite属于嵌入式数据库，设计目标只有一个：作为一个C语言函数库被宿主程序直接调用，数据存储在普通磁盘文件里。MySQL、PostgreSQL则是客户端/服务器架构，有独立的守护进程、网络端口、权限体系，客户端通过TCP/IP协议连接服务器再发SQL。

打个比方，MySQL像一个专门的物业公司，你想回家要给它打电话，它在楼里有一整间办公室；SQLite则像你家门上自带的指纹锁，开锁的逻辑就在锁芯里，不需要额外找物业。SQLite的所有SQL操作，发生在你的程序进程内部，没有网络往返，没有后台守护进程，所以它极轻、极快、极省资源。代价也很明显：它不是一个可供多个进程同时写入的共享服务，并发能力和在线服务能力被刻意砍掉了。

把SQLite和CSV/JSON文件对比就更有意思了。用文件存数据，看似“零依赖”，但一旦涉及修改单条记录、跨文件关联查询、并发防冲突，代码量会迅速失控。SQLite在保留“一个文件就是全部”的简单性之外，把SQL查询、事务、索引、约束这些成熟关系型数据库能力都给了你。一句话：它在“纯文件”和“大型数据库”之间，取了一个对本地存储最友好的平衡点。

1.2 单文件、零配置、跨平台，这三个词的真实含义

“单文件”这个特性初看没什么，实际用起来才知道多幸福。SQLite数据库对外就是一个独立的.db文件，备份、迁移、传输都是复制粘贴的事。我经常在开发机上调试完，直接把.db文件通过网盘发到测试机上，再把路径换成测试环境，数据就完整过去了。相比之下，MySQL的物理备份要考虑数据目录、日志、权限表，操作起来非常重。

“零配置”也不是一句空话。很多数据库在装好之后还要调内存参数、字符集、连接池、用户权限，SQLite引入库就能用。它默认配置已经足够覆盖90%的本地场景，按需调整就是几个PRAGMA语句的事。

“跨平台”则体现在两方面：第一，SQLite本身可在Windows、Linux、macOS、Android、iOS上编译运行；第二，它的数据库文件格式是跨架构通用的。你在x86的Windows机器上创建了一个.db文件，直接扔给ARM架构的路由器，一样能正常打开。这一点在物联网设备、安卓端、桌面端混合的开发场景里极其重要。

1.3 本地存储场景中，SQLite比JSON文件强在哪

如果只存个把配置项，JSON文件完全够用。一旦数据量上百条、需要按条件筛选、需要保证多个字段之间的数据完整性，文件方案就开始露馅了。我举一个真实做过的小工具例子：本地图片管理器，要为每张图片记录路径、拍摄时间、标签、评分。用JSON存，加载时要全部读进内存，查询时手写filter和sort，改一条记录就要重写整个文件，而且多个进程同时读写时还得自己加锁。换成SQLite之后，索引、WHERE、ORDER BY、事务全部现成，改一条记录只需要UPDATE语句，数据库自身保证原子性，数据量上万条也毫无压力。

更重要的是，SQLite的SQL能力让很多复杂逻辑可以下沉到数据库层完成，应用代码只需要拼SQL、读结果，逻辑清晰很多。包括UNIQUE约束、CHECK约束、外键约束这些东西，在JSON方案里全部要靠业务代码手工维护，遗漏一个分支就是数据脏了。所以，当数据开始有结构、有查询需求、有“必须不能丢”的完整性要求时，SQLite就是比文件更合适的那一层。

2. 单文件数据库的底层真相：存储格式、类型系统与事务模型

我一直觉得，用SQLite不能只停留在“会用CRUD”的层面。很多诡异问题的根源都在底层实现上，比如为什么删除数据后文件不缩小，为什么某条脏数据能插入成功，为什么并发一高就报database is locked。理解SQLite的存储格式、类型亲和性、锁机制以后，这些问题基本都能自己推断出来。

2.1 数据库文件里到底装了什么

SQLite把整个数据库放在一个普通磁盘文件里，文件头占用100字节，存储了格式版本、页大小、编码方式等信息。文件剩余部分被划分成固定大小的页（page），默认一页4096字节，页与页之间有B-tree索引组织。为什么要用页？因为SQLite所有的磁盘读写都以页为单位，类似于操作系统以块为单位读写硬盘，这样可以减少随机IO次数。

一张普通表的底层是一棵B+树，树节点正好是一页。表数据本身也放在这棵B+树的叶子节点上。索引同样是一棵独立的B+树，叶子节点保存索引键值和对应的rowid。所以每增加一个索引，数据库就会多出一棵树，这也是索引会占空间的根本原因。

值得留意的是，SQLite文件格式官方给了一套公开的规范，所有版本的SQLite都兼容老格式，新版本也能打开旧版本创建的数据库文件。这意味着你完全可以把数据库文件当作一种稳定的数据交换格式。只要对方装了SQLite，就能直接读你的文件，不用导出再导入，少了很多格式转换的麻烦。

2.2 宽松的类型系统：一个优点，也是一个隐患

熟悉MySQL的人第一次在SQLite里建表，一定有过这样的疑惑：为什么我在INTEGER列里插入一个文本字符串也没报错？这是SQLite的设计哲学之一——动态类型。SQLite每个值本身带有类型标签，存储类一共五种：NULL、INTEGER、REAL、TEXT、BLOB。表里某个列声明成INTEGER，并不像MySQL那样强制校验，它只是表达一种“亲和性”，表示这个列更倾向于存整数。

举个例子，有一列声明为INTEGER，往里面插入字符串“abc”，SQLite允许，只是存成TEXT类型；插入字符串“123”，SQLite认为它长得像数字，会尝试转成INTEGER再存；插入浮点数，会尝试转成INTEGER。这种宽松策略在快速开发时很省心，不用提前把所有类型钉死，但反过来，如果靠它来保证数据质量，早晚要出事。

所以我的习惯是：即便SQLite类型很宽松，建表时依然要明确写清每个字段的声明类型，并且用CHECK约束来兜底。比如金额字段可以加CHECK(amount >= 0)，状态字段加CHECK(status IN (0, 1, 2))，把业务规则的校验责任交给数据库，而不是全压在业务代码上。另一个隐藏点：SQLite的FOREIGN KEY外键约束默认是关闭的，必须在每次连接后执行PRAGMA foreign_keys = ON;，否则建了外键也形同虚设，这个坑几乎每个人都踩过。

2.3 “database is locked”背后的锁机制与WAL模式

SQLite是单写者数据库，这意味着任意时刻只允许一个连接写数据，写的时候会锁住整个数据库文件。它实现了多级锁：读锁是共享的，多个连接可以同时读；写锁是排他的，一个连接在写，其他所有连接的读也会被阻塞，直到写事务结束。这个锁粒度是“整个数据库”，不是某一行某一页，所以并发的自由度天然比MySQL低。

初学阶段遇到database is locked，第一反应基本是“程序出bug了”，其实大部分是锁等待超时。默认情况下，另一个连接持锁超过busy_timeout指定的时间（默认是0，也就是立即失败），就会抛这个错。解决办法不是去调什么神秘参数，而是想清楚自己的事务边界：保持短事务、避免在网络请求或用户输入期间一直持锁、避免在多个线程里共用一个连接。

WAL模式（Write-Ahead Logging）是解决读写冲突最有效的手段。开启WAL后，写操作先把日志追加到独立的-wal文件，不需要直接改动主库文件，因此写操作不再阻塞读操作，读操作也能读到已提交的最新数据。对本地App来说，WAL几乎是必开项，一条PRAGMA journal_mode=WAL;就能让并发体验提升一个档次。但它也不是没有代价，WAL模式下数据库目录里会出现.db-wal和.db-shm两个临时文件，备份时必须连它们一起考虑，或者让所有连接干净关闭后再拷主文件。

3. 高频CRUD里最容易被忽视的细节：自动序号、UPDATE行为与文件收缩

很多开发者用SQLite的时间长了，会觉得自己CRUD已经玩得很溜，但真到写代码时还是会在几个细节上卡住。比如插入一条订单后怎么拿到自增id，UPDATE一些行后怎么确认更新了几行，DELETE后数据库文件为什么还是老大小。这些点单个拎出来不复杂，但组合在一起，体现的是对SQLite行为的理解深度。

3.1 先建一张能说明问题的订单表

为了方便后面展开，我建一张贴近实际业务的订单表。它在后面的示例里会反复用到：

CREATE TABLE IF NOT EXISTS orders ( id INTEGER PRIMARY KEY AUTOINCREMENT, order_no TEXT NOT NULL UNIQUE, customer_name TEXT NOT NULL, amount REAL NOT NULL DEFAULT 0, status INTEGER NOT NULL DEFAULT 0, create_time TEXT NOT NULL DEFAULT (datetime('now', 'localtime')) );

id列采用INTEGER PRIMARY KEY AUTOINCREMENT，这是SQLite里最常用的自增主键写法。有一点需要说明：在SQLite里，只要声明了INTEGER PRIMARY KEY，这个列就会成为rowid的别名，并不一定非要AUTOINCREMENT。不写AUTOINCREMENT时，新插入行默认取“当前最大rowid+1”作为主键，但如果你删除了表中最大的那条记录，新行可能复用这个被删除的id。加了AUTOINCREMENT之后，SQLite会额外维护一张sqlite_sequence表，保证id只增不减，永不复用。

代价是AUTOINCREMENT会多一次写sqlite_sequence表的操作，虽然性能影响微乎其微，但如果你根本不需要“永不复用”这个特性，完全可以只用INTEGER PRIMARY KEY。很多ORM生成的表默认带AUTOINCREMENT，其实是为了在主从复制或数据恢复时避免ID冲突，本地场景大多数时候没必要。

3.2 INSERT之后拿到自动序号的正确姿势

插入数据之后立刻要拿到新记录的id，这是最常见的场景。SQLite提供last_insert_rowid()函数，它返回当前数据库连接中最近一次成功INSERT所产生的rowid。关键点：它是连接级别的，不是全局的，更不是表级别的。如果你在另一个连接里调用，拿到的可能是另一个连接的行为，甚至为0。

在Python的sqlite3模块里，游标对象直接暴露了lastrowid属性：

import sqlite3 conn = sqlite3.connect("demo.db") cur = conn.cursor() cur.execute( "INSERT INTO orders(order_no, customer_name, amount) VALUES (?, ?, ?)", ("SO20240415001", "张三", 199.00), ) print("新订单ID:", cur.lastrowid) conn.commit()

在Android原生的SQLiteDatabase里更直接，insert方法的返回值就是新行的rowid：

ContentValues values = new ContentValues(); values.put("order_no", "SO20240415001"); values.put("customer_name", "张三"); values.put("amount", 199.00); long newId = db.insert("orders", null, values);

这里有几个容易出错的细节。第一，多线程场景下不要跨线程共用一个连接去取值，连接是线程不安全的，应该每个线程都用独立的连接，这样才能保证last_insert_rowid是自己这条链路上的值。第二，如果你插入的是批量数据，最后一次插入的rowid就是本批次最后一条的rowid，要想拿到整批的id范围，需要自己在应用层记下批量起始值再推算。第三，使用ORM时，ORM通常已经帮你封装好了，但如果你执行的是原生SQL，还是要手动调用上面的取id方法。

3.3 UPDATE语句的典型写法与“忘写WHERE”的抢救方案

UPDATE是日常高频操作，写法本身不复杂：

UPDATE orders SET status = 1 WHERE order_no = 'SO20240415001';

再复杂一点的场景是按条件批量更新，比如把所有金额大于500的未支付订单标记为“待审核”状态：

UPDATE orders SET status = 2 WHERE amount > 500 AND status = 0;

有时候需要在一次UPDATE里根据不同条件设置不同值，可以用CASE表达式：

UPDATE orders SET status = CASE WHEN amount < 100 THEN 0 WHEN amount < 500 THEN 1 ELSE 2 END WHERE id > 0;

但最经典的坑还是那句：UPDATE忘记写WHERE。一旦漏掉WHERE，整张表的所有行都会被更新，轻则数据异常，重则直接摧毁整张表的数据。我在本地调试时发生过不止一次，所幸SQLite支持事务回滚。我的抢救方案很朴素：所有UPDATE操作都先包在事务里，执行完先查一下受影响行数和关键字段，确认无误再COMMIT，否则直接ROLLBACK。

还有一点容易被忽略：想要知道UPDATE影响了多少行，SQLite提供了sqlite3_changes()函数，Python里对应cursor.rowcount，Android里对应SQLiteDatabase的changeCount。这个值在判断“更新是否真的命中了目标行”时非常有用，比如根据单号更新订单，更新完发现rowcount是0，说明这个单号根本不存在，可以提前发现业务数据异常。

3.4 DELETE掉的数据为什么不释放空间

DELETE语句从逻辑上删掉了记录，但数据库文件的大小往往纹丝不动。原因是SQLite删除数据后，被释放的页会进入一个“空闲页链表”，供后续INSERT复用，但物理空间并不会主动还给操作系统。这就好比你在一个仓库里挪走了一些箱子，货架空出来了，但整栋仓库的建筑还在，面积没有变小。

想让文件真正变小，需要执行VACUUM。这个命令会重建整个数据库文件，把空闲页压缩掉，相当于把仓库推倒重建，只保留实际在用的货物。VACUUM的操作注意点有三条：

1. 执行期间需要额外磁盘空间，因为SQLite会创建一个临时文件。
2. 执行期间会持有排他锁，其他读写全部阻塞，不要在业务高峰期执行。
3. 频繁执行VACUUM反而会加剧文件碎片，建议在批量清理数据之后执行一次即可。

如果你希望数据库文件长期保持收缩习惯，可以在建库早期执行PRAGMA auto_vacuum = FULL;，但这同样会带来一定的写放大，而且必须在建表之前设置。权衡下来，大部分本地场景我都不开auto_vacuum，而是每次清理完数据后手动VACUUM一次，简单可控。

4. 让日常开发效率翻倍的工具：sqlite3命令、DB Browser与Android可视化

SQLite的上手成本低，很大程度得益于工具链简单。我日常最多用的是三个东西：终端里的sqlite3命令、DB Browser for SQLite图形界面、以及Android Studio内嵌的数据库查看工具。它们覆盖了脚本化、可视化和移动端调试三类场景。

4.1 sqlite3命令行：脚本化操作和排障的利器

sqlite3命令行工具是SQLite官方自带的，装上就有。它既可以交互式使用，也可以直接跟在命令后面执行单条SQL，非常适合脚本和快速排查场景。比如想直接看库里有哪几张表：

sqlite3 demo.db ".tables"

想导出一条简单的查询结果，用管道把SQL传过去：

sqlite3 demo.db "SELECT order_no, amount FROM orders WHERE status = 0;"

真正进入交互模式后，有一批点命令（dot command）会经常用到，我整理了一份常用的放在下面：

.dump和.backup是文件备份里最常用的两个命令。区别在于.dump导出的是SQL文本，需要重建库时用；.backup生成的是SQLite底层页级别的备份文件，更安全高效，支持在线备份，但要求目标库不存在或为空。

4.2 DB Browser for SQLite：适合什么都不想敲的场合

DB Browser for SQLite（DB4S）是我在桌面上最常用的图形化工具，Windows、macOS、Linux都有。它最常用的几个功能：

1. 查看表结构和索引：左侧数据库结构面板能直接看每张表的字段、类型、约束。
2. 执行临时SQL：写复杂SQL时，先在DB4S里跑通了再贴回代码，比在应用里反复跑日志高效。
3. 浏览和编辑数据：双击单元格直接改值，适合手工修正测试数据。
4. 导出/导入CSV：做数据搬运、从Excel数据转成SQLite表非常方便。

DB4S唯一不太强的是对一个库文件进行大规模并发操作的能力，但这不是它的定位。我通常用它做“瞪眼排查”：某个查询结果和预期不一致，直接在图形界面里跑一遍，看原始数据长什么样，比在代码里加日志更快。

4.3 Android Studio中查看和调试应用数据库

移动端开发遇到数据库问题，最麻烦的是看不到数据。过去要么用反射把.db文件从应用私有目录拷出来，要么把设备root后再去/data/data目录下翻。现在Android Studio内置了App Inspection工具（旧版本叫Database Inspector），可以直接查看运行中App的数据库、执行SQL、观察实时变化。

使用条件很宽松：App以debug方式运行，系统API等级26以上（Android 8.0+），模拟器和真机都行。操作步骤：

1. 在Android Studio里运行App。
2. 在底部菜单栏打开View → Tool Windows → App Inspection。
3. 切换到Database Inspector标签页。
4. 找到应用数据库下的表，就能看到实时数据。还可以在Query框里执行任意SQL。

这个工具最有用的一点是实时性。你在App里触发一次数据插入，Database Inspector里立刻能看到新行出现，对于调试“数据到底写没写进去”这类问题，效率极高。

如果想把设备里的数据库文件导出来做离线分析，可以用adb命令。以包名为com.example.app、数据库文件名为app.db为例：

adb exec-out run-as com.example.app cat /data/data/com.example.app/databases/app.db > app-backup.db

这条命令对debug包通常有效，它利用run-as进入应用私有目录读取文件，再把内容重定向到本地。注意如果数据库开了WAL模式，最好先确保App干净退出，连同.db-wal文件一并导出，否则可能拿到不完整的数据。

5. 跨平台落地：Android原生、uniapp与本地云存储架构中的SQLite

SQLite最舒服的舞台在端上：Android、iOS、桌面客户端，以及各类嵌入式设备。聊完工具之后，我用几个实际技术栈来串一遍，包括Android原生的接入方式、uniapp App端的调用方式，以及一类比较典型的“本地库+云端”架构。

5.1 Android原生该用SQLiteOpenHelper、SQLiteDatabase还是Room

Android原生操作SQLite，常见路数有三套：直接用SQLiteOpenHelper管理数据库，裸写SQLiteDatabase增删改查；接入ORM框架，比如官方推荐的Room。三套方案各有取舍，我按项目规模来选。

SQLiteOpenHelper配合SQLiteDatabase是最底层的用法，灵活度高，适合数据库操作不复杂、不想引入额外依赖的项目。典型流程是写一个类继承SQLiteOpenHelper，在onCreate里建表，onUpgrade里做迁移。初版可以写得很粗暴：

public class DBHelper extends SQLiteOpenHelper { public DBHelper(Context context) { super(context, "app.db", null, 1); } @Override public void onCreate(SQLiteDatabase db) { db.execSQL( "CREATE TABLE orders( " + "id INTEGER PRIMARY KEY AUTOINCREMENT, " + "order_no TEXT NOT NULL UNIQUE, " + "customer_name TEXT NOT NULL, " + "amount REAL NOT NULL DEFAULT 0)" ); } @Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { db.execSQL("DROP TABLE IF EXISTS orders"); onCreate(db); } }

但正式项目里，onUpgrade千万别写DROP TABLE这种操作，否则用户升级App时数据全没了。正确做法是按oldVersion到newVersion逐版本执行ALTER TABLE迁移脚本，或者至少先备份老表再重建。

如果你的项目里数据库表比较多、查询逻辑复杂，Room会是更好的选择。它通过注解定义Entity、Dao、Database，在编译期生成大量模板代码，还能把SQLite的cursor到对象的转换过程自动化。Room的底层其实还是SQLite，所以本文讲的SQLite特性在Room里依然适用，只是用法上被封装了。

5.2 uniapp App端通过plus.sqlite管理本地库

跨平台开发里，uniapp是很常见的选择。注意，uni-app本身提供了一些本地存储API，比如uni.setStorage，适合存小配置对象，但如果你要存几百上千条结构化数据并做查询，就应该用SQLite。在uni-app的App端，可以通过plus.sqlite这一组HTML5+ API操作本地数据库。

它的用法非常直接。先打开数据库，再执行建表和增删改查：

plus.sqlite.openDatabase({ name: 'demo', path: '_doc/demo.db', success: function() { plus.sqlite.executeSql({ name: 'demo', sql: 'CREATE TABLE IF NOT EXISTS orders(id INTEGER PRIMARY KEY AUTOINCREMENT, order_no TEXT, amount REAL)', success: function() { console.log('建表成功'); }, fail: function(err) { console.log('建表失败', JSON.stringify(err)); } }); }, fail: function(err) { console.log('打开数据库失败', JSON.stringify(err)); } });

查询用selectSql，同executeSql类似，只是sql传SELECT语句。注意plus.sqlite只支持App端，H5和微信小程序里没有这套API。如果要在小程序里做本地结构化存储，只能换方案，比如用小程序自己的本地缓存自行封装，或者接入云数据库的本地缓存能力。

用plus.sqlite的时候，我遇到最多的两个问题：一个是路径写错，path参数要按HTML5+规范的相对路径来写，例如“_doc/”表示应用私有文档目录；另一个是API参数版本差异，所以写代码前最好对照当前HBuilderX对应的官方文档，别凭记忆硬写。

5.3 从本地数据库到云端：视频类应用的存储分层思路

回到前面提到的一个热搜词“视频本地云存储架构”。这类场景的核心矛盾是：原始视频文件很大，云端负责内容存储和分发，但端上又必须快速响应用户操作，不能让所有读操作都依赖网络请求。实际上最常见的分层做法是：云端存视频原片和元数据，本地SQLite存播放进度、收藏状态、离线下载任务、推荐列表缓存这些高频访问的小数据。

SQLite在这里的价值很明确：它是本地离线优先架构的“状态中心”。App启动时先读本地库，秒级渲染界面，同时后台向云端拉取增量数据，回来后更新SQLite并刷新界面。这样即使断网，用户的播放记录、收藏列表也不会丢。数据规模可控，查询需求明确，并发量低——这就是SQLite最擅长的工作位置。

数据备份与迁移在这个架构里也很重要。定期把SQLite文件备份到云端，或者把关键表导出成JSON同步上去，都是常见做法。SQLite的.backup命令可以生成一致性快照，适合做定时备份；.dump导出的SQL文本则适合做跨版本迁移。本地到云端、云端到本地，两条通路都打通之后，这个存储层就稳了。

6. 性能与稳定性：把SQLite用稳的实践经验

这一部分是我自己踩坑最多的地方。SQLite平时很乖，但一旦触发并发写冲突、文件损坏、查询性能退化，定位起来还是要费一番功夫。下面几条经验，值得在项目初期就纳入设计考虑。

6.1 并发写冲突的排查链路与解决顺序

遇到database is locked，我的排查顺序是固定的：

1. 先看有没有长事务。在同一个事务里执行了网络请求、大量循环等待，相当于长时间握住写锁不放。解决办法是把事务拆短，提交后再做耗时操作。
2. 再看是不是有多个连接同时写。SQLite同一时间只允许一个写者，即使是不同表也一样。如果是多线程写入，要么串行化，要么用单个写线程所有写请求排队执行。
3. 开启WAL模式。它能让读写并行，很多读写互相阻塞的问题在WAL下直接消失。
4. 设置合理的busy_timeout。默认是0，改成3000到5000毫秒，多数瞬时锁竞争就能自动等待而非立刻报错：

PRAGMA busy_timeout = 5000;

最后一条兜底原则：SQLite不是为高并发写设计的。如果单机写入速度超过每秒几百甚至上千次，或者有多个进程同时频繁写，就该认真考虑换用其他数据库或引入消息队列做异步落库，而不是继续压榨SQLite的锁机制。

6.2 数据库损坏的预防、检测与恢复流程

SQLite文件损坏，大多数情况是掉电、进程被杀、或者数据库文件在同步过程中被复制了一半。很多人以为这个概率很低，但实际在嵌入式设备和弱网环境下，概率并不小，尤其当WAL模式下来不及合并日志时，把不完整的-wal文件一起拷走也会带来问题。

预防为主，我通常做两件事。一是把synchronous设为NORMAL，这个级别在WAL模式下既能保证基本一致性，性能也不会太差；二是备份时不用简单的文件复制，而是用.backup命令或VACUUM INTO生成一致性快照，避免备份到“写到一半”的库。

检测损坏用内置的完整性检查命令：

PRAGMA integrity_check;

如果返回ok，说明结构完整。返回其他信息，比如malformed database schema、database disk image is malformed，就需要抢救数据。我的恢复步骤是：先把损坏文件备份一份，再用sqlite3命令尝试导出可读部分：

sqlite3 damaged.db ".dump" > recovery.sql

这个命令会尽可能把能读的表和数据以SQL形式导出。导出完成后，新建一个空库，再导入recovery.sql：

sqlite3 new.db < recovery.sql

能救回来多少算多少，至少业务表的核心数据大概率能保住。说实话，真到了这一步，修复本来就是“尽人事”，所以定期备份才是王道。

6.3 索引怎么加才有效，EXPLAIN QUERY PLAN的使用

索引不是越多越好。本地场景数据量通常不大，几万条以内，全表扫描很多时候也就几十毫秒，这时候加一堆索引反而拖慢写入速度。但当查询开始变慢时，索引是性价比最高的解法。

我加索引的判断依据很简单：WHERE、JOIN、ORDER BY里高频出现的列才加。比如按customer_name查订单，就可以加上：

CREATE INDEX idx_orders_customer ON orders(customer_name);

加完要验证是否真的被用上，用EXPLAIN QUERY PLAN看执行计划：

EXPLAIN QUERY PLAN SELECT * FROM orders WHERE customer_name = '张三';

执行计划里出现SCAN orders，说明是全表扫描；出现SEARCH orders USING INDEX idx_orders_customer，说明索引生效了。这里有个常见误区：LIKE '%xxx%'这种前导通配查询用不了普通索引，只有LIKE 'xxx%'前缀匹配才能命中。还有，在列上做函数运算，比如WHERE date(create_time) = '2025-01-01'，同样会使索引失效，应该直接比对原始列的区间范围。

6.4 一套我常用的PRAGMA配置参考

最后把我常用的PRAGMA配置整理成一张表，本地App类项目可以直接参考。每个参数的含义写清楚，方便按项目实际情况调整：

把这些写在一个连接初始化方法里，每个新连接打开后执行一遍。这个习惯我坚持了很久，尤其foreign_keys这条，很多项目建了外键却没有开启它，导致约束完全无效，直到数据出问题才反应过来。

最后分享一个我的个人习惯：每次改动表结构之前，先执行一次.backup，把当前库完整备份到单独目录。SQLite的迁移不像大型数据库那样有成熟的前置校验机制，多一份备份，就少一分“升级后数据全乱”的焦虑。本地存储这件事，简单是它的优势，但正因为简单，很多保障措施要靠使用者自己补上。