多进程操作SQLite遇SQLITE_BUSY，配置参数后仍疑似锁库

核心问题分析 #

• 开启WAL模式后，SQLite的读写并发逻辑是读操作不阻塞读、读不阻塞写、写阻塞读/写，但如果写操作持有锁的时间过长，或者重试策略不合理，确实可能导致看似“锁定”的现象。
• 300ms的重试间隔其实不算频繁，但如果你的写操作本身耗时较长（比如批量插入大数据），短间隔重试会让多个进程持续争抢锁，反而加剧资源占用，导致其他操作长时间等待，看起来像数据库被锁定。

针对性解决方案 #

1. 调整重试策略 #

• 不要用固定短间隔重试，改用指数退避策略：第一次等100ms，第二次200ms，第三次400ms，最多重试5-6次，避免进程扎堆争抢锁。
• 代码示例（伪代码）：

  import time
  
  def execute_with_retry(db, query, max_retries=5):
      retries = 0
      while retries < max_retries:
          try:
              return db.execute(query)
          except sqlite3.OperationalError as e:
              if "database is locked" in str(e):
                  wait_time = 100 * (2 ** retries)
                  time.sleep(wait_time / 1000)
                  retries += 1
              else:
                  raise
      raise Exception("Max retries exceeded")
  

2. 优化WAL相关配置 #

• 检查journal_mode是否确实设置为WAL：执行PRAGMA journal_mode=WAL;确认返回wal。
• 调整wal_autocheckpoint参数，默认是1000页，如果你有大量写操作，可以调大到5000或更高，减少自动检查点的频率（检查点会短暂阻塞写操作）：PRAGMA wal_autocheckpoint=5000;。
• 手动触发检查点：在低峰期执行PRAGMA wal_checkpoint(FULL);，避免自动检查点在高并发时拖慢性能。

3. 优化读写操作 #

• 写操作尽量批量执行，减少单次操作的次数：比如用executemany代替多次execute，减少锁持有时间。
• 读操作尽量使用只读连接：在连接时设置isolation_level=None并执行PRAGMA query_only=1;，这样读操作不会参与锁争抢，提高并发能力。
• 避免长时间持有事务：不要在事务里做非数据库操作（比如网络请求、计算），尽快提交或回滚事务。

4. 排查疑似锁定的真实原因 #

• 用SQLite的PRAGMA busy_timeout;确认当前超时设置，WAL模式下合理的超时可以设为3000ms（3秒），给足够时间等待锁释放。
• 查看数据库目录下的*.wal和*.shm文件，如果这些文件持续变大不消失，说明检查点没正常执行，可能是写操作一直没完成，导致WAL文件无法清理，进而影响性能。
• 用进程监控工具（比如Linux的lsof、Windows的Process Explorer）查看哪些进程在占用数据库文件，确认是否有进程长期持有连接未释放。

总结 #

300ms的固定重试间隔本身不一定是问题根源，但搭配不合理的操作逻辑（比如长事务、频繁单条写）会放大并发冲突。优先从优化事务时长、调整重试策略、配置WAL参数这几个方向入手，逐步排查就能解决疑似锁定的问题。

内容的提问来源于stack exchange，提问作者sinkhaha