SQLite作为嵌入式的文件型数据库，常被用于桌面软件、移动端和小型服务端。它和常见的客户端服务器数据库不同，没有独立的数据库进程，所有读写都直接通过宿主程序对磁盘文件进行操作。这种架构决定了它的连接与并发模型和传统数据库存在本质区别。很多人在设计系统时会关心它最多能开多少连接，以及并发读写时是否会互相干扰，这需要从文件、锁机制和事务模型几个层面分别剖析。
连接数量的实际边界在哪里
从SQLite引擎自身来看，它并没有在代码里规定一个最大连接数。也就是说，你用C、Python或Java同时打开一百个、一千个数据库连接对象，SQLite库本身不会报错拒绝。真正约束连接数的是运行环境：每一个连接对应一个打开的数据库文件描述符，操作系统对单个进程能打开的文件句柄数有限制，例如Linux默认软限制常常是1024。当连接数超过这个限制，打开新连接就会失败并返回系统级错误。
除了文件描述符，每个连接还会占用一定的内存用来缓存页、语句句柄和事务状态。如果盲目创建大量长生命周期的连接且不关闭，内存会持续上涨，最终可能触发OOM。因此在实践中，即便SQLite不限制连接数，我们也应该使用连接池控制数量，而不是无节制地创建。下面的Python示例展示了如何使用简单池化来约束连接规模：
import sqlite3
from queue import Queue
class SQLitePool:
def __init__(self, db_path, max_size=10):
self.pool = Queue(maxsize=max_size)
for _ in range(max_size):
# 每个连接都是独立的文件描述符
conn = sqlite3.connect(db_path, check_same_thread=False)
self.pool.put(conn)
def get_conn(self):
return self.pool.get()
def put_conn(self, conn):
self.pool.put(conn)
pool = SQLitePool("app.db", max_size=5)
conn = pool.get_conn()
cursor = conn.execute("SELECT 1")
print(cursor.fetchone())
pool.put_conn(conn)
上面的代码通过队列把连接数固定在5个，避免了频繁打开关闭文件，也防止了句柄耗尽。如果你的应用是多线程环境，还要注意SQLite默认不允许跨线程使用同一个连接，除非在打开时设置了check_same_thread=False，或者使用独立的连接给每个线程。这种资源约束虽然不在SQLite内部，但比任何内部上限都更先起作用。
并发读写的锁机制与单写者限制
SQLite的并发控制核心是锁。它对数据库文件施加不同级别的锁：未加锁、共享锁、保留锁、待写锁和排写锁。多个连接可以同时持有共享锁进行读操作，所以读可以并发。但一旦有连接要写入，就必须获取排写锁，这时其他所有连接既不能写也不能读，直到写事务提交或回滚释放锁。这就是所谓的单写者模型，同一时刻只有一个写事务能成功。
当写者正在工作时，其他尝试读或写的连接会立刻收到SQLITE_BUSY错误，而不是排队等待。开发者必须在应用层处理这个错误，比如重试或者降低写入频率。下面的示例演示了捕获忙错误并进行简单退避重试的逻辑：
import sqlite3
import time
def safe_write(db_path, sql):
for attempt in range(5):
try:
conn = sqlite3.connect(db_path)
conn.execute(sql)
conn.commit()
conn.close()
return True
except sqlite3.OperationalError as e:
if "database is locked" in str(e):
time.sleep(0.1 * (attempt + 1))
continue
else:
raise
return False
safe_write("app.db", "INSERT INTO logs(msg) VALUES('test')")
从底层看，这种锁是文件锁，依赖操作系统提供的机制，因此在网络文件系统如NFS上并不可靠，可能导致两个机器同时写而损坏数据库。这也是SQLite官方不推荐将其用于多机并发写入的原因。即便在单机，高并发写入也会因为频繁抢锁而性能骤降，此时应考虑把写操作合并成批处理，或者改用客户端服务器数据库。
WAL模式带来的并发改善与残余约束
为了解决读写互斥导致读被写阻塞的问题，SQLite提供了WAL（Write-Ahead Logging）模式。在WAL下，写操作不再直接修改主数据库文件，而是先追加到单独的-wal文件中，读操作可以继续读取主库旧版本页面，从而实现读写并发。这样读者不会因写者存在而失败，显著提升了读多写少场景的体验。
开启WAL非常简单，只需执行一条PRAGMA语句。但要注意WAL并没有取消单写者限制，写事务之间依旧互斥。而且WAL文件需要定期checkpoint合并回主库，否则磁盘占用会增长。以下代码展示如何启用并配置WAL：
-- 开启WAL模式 PRAGMA journal_mode=WAL; -- 设置wal文件自动checkpoint的阈值 PRAGMA wal_autocheckpoint=1000;
在移动端应用中，WAL能明显减少界面卡顿，因为UI线程的读不会被后台写阻塞。但若你的业务是高频写例如每秒上千次插入，即使WAL也无法让多个写者并行，仍要靠队列串行化写入。理解WAL只是缓解而非消除并发限制，才能正确评估SQLite是否适配你的系统规模。对于真正需要多写并发的后端服务，应当选择PostgreSQL或MySQL这类支持多写者锁粒度的数据库。
如何根据限制设计合理的访问层
面对SQLite的连接与并发特性，架构上最务实的做法是把所有写操作收拢到单一线程或单一连接，读操作则可以分散。这种生产者消费者模型能够彻底规避SQLITE_BUSY，也降低锁竞争。许多嵌入式设备上的数据采集程序就是这么做的：一个线程负责落盘，其他线程把数据塞进内存队列。
另外，合理设置忙超时比手动重试更省心。SQLite提供busy_timeout编译指令，让引擎在锁冲突时自动等待一段时间而非立即报错。示例如下：
import sqlite3
conn = sqlite3.connect("app.db")
# 设置忙超时三秒，期间自动重试获取锁
conn.execute("PRAGMA busy_timeout=3000")
conn.execute("INSERT INTO t(v) VALUES(1)")
conn.commit()
conn.close()
结合连接池、WAL和忙超时，SQLite足以支撑中小型本地应用的并发需求。但务必记住它始终面向单机和单写者，将其暴露在公网多实例写入场景必然引发数据问题。清楚认识最大连接数来自系统而非引擎、并发限制来自锁而非代码，才能用得安稳。