6月1日 00:06

SQLite 连接池该不该用，如何避免锁和连接泄漏？

SQLite 连接池要先问“该不该用”，再问“怎么实现”。SQLite 是嵌入式数据库，数据库引擎就在应用进程里，连接本质上是打开本地文件和维护一组状态，并不像 MySQL、PostgreSQL 那样要跨网络建立远程会话。连接池真正有价值的场景，是 Web 服务、多线程任务或频繁短连接脚本需要统一管理连接、事务、超时和关闭流程。它能减少连接管理混乱，但解决不了 SQLite 的单写者并发边界；连接越多，写冲突有时反而越明显。

python
import sqlite3
from queue import Queue, Empty

class SQLitePool:
    def __init__(self, path, size=4):
        self.pool = Queue(maxsize=size)
        for _ in range(size):
            conn = sqlite3.connect(path, timeout=5, check_same_thread=False)
            conn.execute('PRAGMA journal_mode=WAL')
            conn.execute('PRAGMA foreign_keys=ON')
            self.pool.put(conn)

如果只是为了减少样板代码，也可以不写完整连接池，而是写一个连接管理器，在进程启动时创建连接、退出时关闭。连接池适合有明确并发任务和资源上限的服务，不适合给所有 SQLite 项目套模板。判断标准很现实：没有观测到连接创建成本、泄漏风险或并发等待，就先保持简单。

如果部署在网络文件系统上，还要额外谨慎，SQLite 对文件锁语义很敏感，连接池无法修复底层锁实现不可靠的问题。

连接池还要配合监控使用，至少记录获取连接等待时间、池中空闲数量、写事务耗时和锁错误次数。没有这些指标时，调大池子或调长超时都只是猜。

对嵌入式应用来说，简单稳定往往比抽象完整更重要，连接池必须服务于明确问题，而不是为了看起来像服务端架构。

追问

SQLite 为什么不像服务端数据库那样天然需要连接池？

SQLite 没有独立数据库服务器，连接成本通常比远程数据库低很多，很多桌面应用、移动应用或 CLI 工具，一个连接配合事务就够了。连接池的收益更多来自资源治理：限制并发连接数、统一 PRAGMA、避免频繁打开关闭、集中处理异常。取舍点在应用形态，单线程脚本加连接池是过度设计，多线程 Web API 每个请求都开关连接则可能需要池化。边界是连接池不能把 SQLite 变成高并发写数据库，同一时间写事务仍然会排队。踩坑是照搬服务端数据库经验，把池子开很大，最后得到的不是吞吐提升，而是更多锁等待。

连接池大小应该怎么设置？

不要按请求并发数机械设置连接数，SQLite 不是连接越多越快。读多写少并启用 WAL 时，可以让多个读连接并发工作，但写入仍然需要控制事务长度和排队方式。一个常见起点是 2 到 8 个连接，然后根据等待时间、database is locked 频率和查询耗时调整。取舍是小池子更容易暴露排队，大池子更容易制造锁竞争和资源占用。踩坑是没有设置获取连接超时，池子耗尽后请求一直卡住，看起来像数据库慢，其实是连接泄漏或事务太长。

python
def acquire(pool, timeout=2):
    try:
        return pool.get(timeout=timeout)
    except Empty:
        raise TimeoutError('SQLite connection pool exhausted')

def release(pool, conn):
    pool.put(conn)

多线程使用 SQLite 连接有哪些坑？

Python 的 sqlite3 默认限制连接只能在创建它的线程使用，所以不少示例会设置 check_same_thread=False。但这只是取消驱动层检查，不代表同一个连接可以被多个线程同时随便操作。更稳的方式是一个连接同一时刻只借给一个请求或任务，事务期间不让连接流转，用完立刻归还。取舍是这种封装会多一些代码，但能换来清晰的所有权和异常边界。边界也要承认：如果业务需要大量并发写入、复杂事务隔离和连接级权限管理，迁移到服务端数据库通常比硬调 SQLite 连接池更省事。

如何避免连接泄漏和脏事务？

连接池最怕借出去后没有归还，或者异常发生时事务没回滚就回到池里。获取连接后要用 try/finally 保证释放，执行写操作时要明确 commit 或 rollback。归还前可以检查连接状态，必要时回滚未完成事务，避免下一个请求接到“带着上个请求现场”的连接。踩坑是把连接对象传到很多层函数里，异常路径越来越多，最后没人确定谁负责释放。比较稳的做法是封装成上下文管理器，让借还、提交、回滚都集中在一个地方。

python
from contextlib import contextmanager

@contextmanager
def pooled_conn(pool):
    conn = acquire(pool)
    try:
        yield conn
        conn.commit()
    except Exception:
        conn.rollback()
        raise
    finally:
        release(pool, conn)

WAL、busy_timeout 和连接池怎么配合？

WAL 模式能让读写并发体验更好，读连接通常不阻塞写连接追加日志，适合服务型应用。busy_timeout 或连接参数里的 timeout 可以让遇到锁时等待一会儿，而不是立刻抛出 database is locked。取舍是等待不是万能药，写事务太长时只会把请求堆起来，用户看到的就是慢。边界很明确：写事务要短，批量写入要集中，长时间计算不要占着事务和连接。踩坑是把网络请求、文件上传、复杂计算放在事务中间，连接池再大也会被慢事务拖住。

标签：Sqlite