数据库SQLite事务与WAL模式读写并发

SQLite的事务机制和WAL（Write-Ahead Logging）模式是解决读写并发问题的核心方案。简单来说，SQLite默认使用DELETE模式（也叫Rollback Journal模式），在这种模式下，写操作会锁定整个数据库，读操作也无法同时进行。而开启WAL模式后，写操作不再阻塞读操作，读写可以真正并发执行，这是SQLite在高并发场景下最重要的性能优化手段。如果你正在用SQLite做本地存储、嵌入式开发或者移动端数据管理，理解这套机制能直接决定你的应用性能上限。

SQLite本身是一个文件型数据库，所有数据都存在一个磁盘文件里。它不像MySQL、PostgreSQL那样有独立的服务进程来管理并发，所有的并发控制都在数据库引擎内部完成。这就意味着，SQLite的并发能力完全取决于它的日志模式和锁策略。搞清楚这一点，你就明白为什么WAL模式如此关键了。

SQLite的事务遵循ACID原则，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。在SQLite中，事务的本质就是把一组SQL操作打包成一个不可分割的单元。要么全部成功提交，要么全部回滚，不会出现中间状态。

SQLite事务有三种类型：DEFERRED（默认）、IMMEDIATE和EXCLUSIVE。DEFERRED事务在第一次读写操作之前不会获取任何锁，这意味着多个连接可以同时打开DEFERRED事务而互不干扰。IMMEDIATE事务在开启时立即获取RESERVED锁，阻止其他连接写入。EXCLUSIVE事务则直接获取排他锁，整个数据库只有它一个人能用。

在代码层面，使用事务非常简单：

import sqlite3

conn = sqlite3.connect('mydata.db')
cursor = conn.cursor()

try:
    cursor.execute('BEGIN DEFERRED')
    cursor.execute('INSERT INTO users (name, age) VALUES (?, ?)', ('张三', 28))
    cursor.execute('UPDATE accounts SET balance = balance - 100 WHERE id = 1')
    conn.commit()
except Exception as e:
    conn.rollback()
    print(f"事务失败: {e}")
finally:
    conn.close()

这段代码展示了最基本的事务用法。BEGIN DEFERRED开启一个延迟事务，中间的INSERT和UPDATE操作要么一起成功，要么一起回滚。关键点在于，如果不显式调用commit()，所有修改都不会真正写入数据库文件。

SQLite默认的日志模式是DELETE模式，也叫Rollback Journal模式。它的工作原理是：在写操作开始之前，先把要修改的数据页的原始内容复制到一个rollback journal文件里。如果事务失败，就用这个journal文件恢复数据。如果事务成功，就删除这个journal文件。

问题就出在这里。在写操作进行期间，SQLite会获取一个EXCLUSIVE锁（排他锁）。这个锁意味着：不允许任何其他连接读取数据库，也不允许任何其他连接写入。所以在DELETE模式下，读和写是完全互斥的。一个写操作正在进行时，所有读请求都要排队等待，直到写操作完成并释放锁。

这种模式在低并发场景下没问题，但如果你的应用有多个线程或者多个进程同时访问数据库，比如一个后台线程在写日志，前台线程在查询数据，那性能就会非常差。写操作频繁时，读操作会被长时间阻塞，用户体验直接崩掉。

WAL模式的核心思想是"先写日志，再写数据"。具体来说，当执行写操作时，SQLite不再修改原始数据库文件，而是把修改追加到一个单独的WAL文件（.db-wal）末尾。读操作则同时从原始数据库文件和WAL文件中合并数据，得到最新的视图。

这样做带来了一个革命性的变化：写操作只需要获取WAL文件的锁，不需要锁定整个数据库文件。读操作可以同时从原始文件读取数据，只要在读取时检查一下WAL文件有没有更新就行。结果就是：读和写可以同时进行，互不阻塞。

开启WAL模式只需要一条SQL语句：

PRAGMA journal_mode = WAL;

执行这条语句后，SQLite会创建一个.db-wal文件和一个.db-shm文件（共享内存文件，用于多进程协调）。之后所有的写操作都会追加到WAL文件，读操作则自动合并两个文件的数据。

WAL模式下的锁机制也完全不同。写操作获取的是WAL文件上的锁，读操作获取的是数据库文件上的共享锁。这两种锁不冲突，所以读写并发成为可能。但需要注意，WAL模式下仍然不允许多个写操作同时进行，写操作之间还是互斥的。

理解WAL模式的读写流程，有助于你在实际开发中做出正确的决策。写流程是这样的：当一个连接要修改数据时，它先获取WAL文件的排他锁，然后把修改的内容以帧（frame）的形式追加到WAL文件末尾，最后释放锁。整个过程非常快，因为是顺序追加写，不需要随机寻址。

读流程稍微复杂一些。当一个连接要读取数据时，它先从原始数据库文件中读取对应的数据页，然后检查WAL文件中是否有对这个数据页的更新。如果有，就把WAL中的修改合并到读到的数据上，返回最新结果。这个过程叫做"checkpoint"的反向操作，但不需要等到checkpoint发生，读的时候实时合并就行。

这里有一个重要的细节：WAL文件会不断增长，如果不管它，文件会越来越大。SQLite通过checkpoint机制定期把WAL文件中的修改合并回原始数据库文件，然后截断WAL文件。你可以手动触发checkpoint：

PRAGMA wal_checkpoint(TRUNCATE);

TRUNCATE参数会把WAL文件中已合并的内容截断，释放磁盘空间。一般建议在应用空闲时或者关闭数据库连接前执行一次checkpoint。

从性能角度看，WAL模式在并发场景下的提升是非常显著的。根据SQLite官方基准测试，在多线程读写混合负载下，WAL模式的吞吐量可以达到DELETE模式的3到5倍。特别是在读多写少的场景（比如大多数Web应用的典型模式），WAL模式几乎可以消除读等待。

另外，WAL模式还有一个隐藏优势：由于写操作是顺序追加，磁盘I/O效率更高。在机械硬盘上，顺序写比随机写快几个数量级。即使在SSD上，顺序写也比随机写更友好。所以WAL模式不仅解决了并发问题，还间接提升了写性能。

但WAL模式也不是万能的。在极端写密集的场景下（比如每秒数千次小事务写入），WAL文件会快速膨胀，checkpoint频繁触发反而可能成为瓶颈。这时候需要根据实际情况调整checkpoint策略或者考虑其他方案。

虽然WAL模式很强大，但有几个限制你必须知道。第一，WAL模式不支持多个进程同时写入。多个进程可以同时读，但写操作仍然是串行的。如果你需要真正的多写并发，SQLite本身就不适合，应该考虑客户端-服务器架构的数据库。

第二，WAL模式在网络文件系统（NFS）上可能出现问题。因为WAL依赖共享内存文件（.db-shm）来协调多进程访问，而NFS对共享内存的支持不可靠。官方明确不建议在NFS上使用WAL模式。

第三，WAL模式下数据库文件的备份需要特别注意。直接复制.db文件可能得到不完整的数据，因为最新的修改可能还在WAL文件里。正确的做法是先执行checkpoint，或者使用SQLite的备份API：

import sqlite3

def backup_database(src_path, dst_path):
    source = sqlite3.connect(src_path)
    dest = sqlite3.connect(dst_path)
    with dest:
        source.backup(dest)
    dest.close()
    source.close()

第四，WAL文件默认大小限制是1000页（约4MB，假设页大小为4KB）。超过这个限制后，SQLite会自动触发checkpoint。你可以调整这个阈值：

PRAGMA wal_autocheckpoint = 500;

这个值设得越小，checkpoint越频繁，WAL文件越小，但可能影响写性能。需要根据你的应用特点做平衡。

在多线程应用中使用SQLite WAL模式，有几个最佳实践值得遵循。首先，每个线程应该使用独立的数据库连接，不要跨线程共享连接对象。SQLite的连接不是线程安全的，共享连接会导致各种奇怪的错误。

其次，合理使用事务来减少锁竞争。不要把每一条SQL都放在单独的事务里，而是把相关的操作打包成一个事务。比如插入1000条记录，放在一个事务里比1000个事务快得多，因为减少了锁获取和释放的开销。

第三，对于读操作密集的场景，可以考虑使用只读连接。SQLite支持以只读模式打开数据库，这样可以避免不必要的锁获取：

conn = sqlite3.connect('file:mydata.db?mode=ro', uri=True)

最后，定期监控WAL文件大小和checkpoint频率。如果发现WAL文件持续增长不收缩，说明checkpoint没有正常触发，可能需要检查是否有长时间运行的读事务阻止了checkpoint。在WAL模式下，任何活跃的读事务都会阻止checkpoint把WAL内容合并回主文件。

不是所有场景都需要WAL模式。如果你的应用是单线程、写操作很少、数据量很小，DELETE模式完全够用，没必要切换。WAL模式的价值主要体现在：多线程或多进程并发访问、读写混合负载、对响应延迟敏感的场景。

一个简单的判断方法：如果你发现应用在写入数据时，查询操作明显变慢或者卡顿，那大概率是DELETE模式下的锁竞争导致的。切换到WAL模式后，这个问题通常会立刻消失。

你可以用以下SQL检查当前的日志模式：

PRAGMA journal_mode;

返回值如果是wal，说明已经开启。如果是delete，说明还在用默认模式。切换后记得重启应用或者重新打开连接，因为已经打开的连接不会自动切换模式。

总结一下，SQLite的事务机制保证了数据的完整性和一致性，而WAL模式则在此基础上解决了读写并发的核心痛点。对于绝大多数本地数据库应用来说，开启WAL模式是性价比最高的优化手段，一行PRAGMA语句就能带来质的提升。但同时也要清楚它的边界，不要把SQLite当成高并发写入的万能方案。