揭开 SQLite "仅限本地" 神话的面纱 历史上，SQLite 被 relegated 为嵌入式数据库，仅用于移动客户端、物联网设备以及本地开发环境。传统智慧认为，任何严肃的生产级 web 应用程序都必须使用客户 - 服务器数据库，如 PostgreSQL 或 MySQL。然而，这一假设忽略了现代硬件架构的重大转变。随着高速 NVMe SSD、超快本地存储的普及，以及单租户边缘部署的趋势，传统数据库的网络往返延迟已成为主要瓶颈。通过直接在同一服务器上的应用程序进程中运行 SQLite，您将完全消除网络开销。读取变为简单的内存映射文件操作，查询执行时间低于毫秒。然而，在生产中运行 SQLite 需要我们改变配置、调整和思考数据库并发的方式。开箱即用，SQLite 配置为最大安全性和兼容性，而不是高吞吐量的应用服务器。要释放其真正潜力，我们必须深入了解其内部机制：预写日志（WAL）、锁定状态、缓存管理和自定义虚拟文件系统（VFS）层。 深入了解预写日志（WAL）模式 默认情况下，SQLite 使用回滚日志机制。在此模式下，在任何写入操作发生之前，原始数据库页面被复制到一个单独的回滚日志文件中。如果事务成功，日志将被删除；如果失败，数据库将使用日志将数据库还原到其原始状态。回滚日志的一个关键缺点是并发：写入阻止读取，读取阻止写入。在写入操作期间，只有一个连接可以访问数据库。要构建一个高度并发的应用服务器，您必须启用预写日志（WAL）模式。 PRAGMA journal_mode = WAL; 在 WAL 模式下，SQLite 不直接修改主数据库文件，而是将新事务附加到一个单独的 .sqlite-wal 文件中。这完全改变了并发的范式： 并发读取和写入：读取者继续从主数据库文件（以及 WAL 中未更改的页面）中读取，而写入者则将新页面附加到 WAL 文件的末尾。读取者和写入者不会相互阻塞。 检查点过程：随着时间的推移，WAL 文件会增长。为了防止它占用过多的磁盘空间并减慢读取操作（必须扫描 WAL 索引以查找页面的最新版本），SQLite 必须定期将 WAL 页面合并回主数据库文件中。这称为检查点。 检查点策略 SQLite 自动处理检查点，但默认行为可能导致延迟峰值。有四种检查点模式： PASSIVE：在不阻塞任何读取者或写入者的情况下合并尽可能多的页面。如果读取者当前正在访问 WAL 中的较旧页面，SQLite 无法覆盖该页面，因此检查点提前停止。 FULL：阻止新的写入事务并等待现有读取事务完成，确保整个 WAL 被合并。 RESTART：类似于 FULL，但还将 WAL 文件大小重置为零，确保后续写入从文件开头开始。 TRUNCATE：与 RESTART 相同，但将 WAL 文件在磁盘上截断为零字节。 对于高写入量的生产服务器，仅依赖 SQLite 的自动检查点可能导致 WAL 文件无限生长，如果始终有一个活动的读取者。为防止这种情况，您应该在后台线程或进程中显式管理检查点，使用 PASSIVE 或 RESTART 检查点按计划间隔进行： PRAGMA wal_checkpoint(PASSIVE); 为确保写入操作不受磁盘同步瓶颈的影响，将 WAL 模式与以下 pragma 配对： PRAGMA synchronous = NORMAL; 在 NORMAL 模式下，数据库引擎仅在关键时刻（例如，在检查点期间）同步到磁盘，而不是在每个事务提交时。在 WAL 模式下，这完全安全，不会导致数据库损坏；即使服务器崩溃，只有 WAL 中未提交的事务会丢失，但数据库完整性仍然得到保持。 并发架构：解决 SQLITE_BUSY 虽然 WAL 模式允许并发读取和写入，但 SQLite 仍然强制执行单写入者模型。在任何给定时刻，只有一个事务可以写入数据库。如果第二个连接在写入事务处于活动状态时尝试写入，SQLite 会立即返回 SQLITE_BUSY 错误。要构建一个可靠的应用程序，您的连接池和事务逻辑必须以优雅的方式处理这一约束。 1. 配置忙碌超时 在没有设置忙碌超时的情况下，永远不要在生产中运行 SQLite。这指示 SQLite 在引发 SQLITE_BUSY 异常之前，尝试在内部重新获取写入锁定的指定持续时间。 PRAGMA busy_timeout = 5000; -- 超时以毫秒为单位（5 秒）