sqlite 的写入并发限制是按数据库文件独立计算的，每个 sqlite 数据库文件（即单个 .db 文件）在任意时刻只允许一个写入事务执行，但该限制不跨数据库文件——也就是说，如果你在同一个应用中同时打开并写入 4 个不同的 sqlite 数据库文件（如 user.db、log.db、config.db、cache.db），这 4 个写入操作可以真正并行进行（由操作系统和文件锁机制保障隔离），不会相互阻塞。
这是因为 SQLite 的写锁（WAL 模式下为写锁 + WAL 文件独占，传统 rollback 模式下为 RESERVED → PENDING → EXCLUSIVE 状态升级）作用域严格限定于单个数据库文件。不同数据库文件拥有各自独立的锁状态和事务日志，彼此无共享资源竞争。
✅ 正确示例（Python）：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
import sqlite3
import threading
def write_to_db(db_path, value):
conn = sqlite3.connect(db_path)
conn.execute("INSERT INTO data (val) VALUES (?)", (value,))
conn.commit()
conn.close()
# 并发写入 3 个不同数据库 —— 实际可并行
threads = [
threading.Thread(target=write_to_db, args=("db1.sqlite", "A")),
threading.Thread(target=write_to_db, args=("db2.sqlite", "B")),
threading.Thread(target=write_to_db, args=("db3.sqlite", "C")),
]
for t in threads: t.start()
for t in threads: t.join()⚠️ 注意事项：
- 同一数据库文件内的多线程/多进程写入仍会排队（即使使用 WAL 模式，也仅允许多读一写，且写入仍需序列化）；
- 频繁跨库事务（如需原子性地更新多个 DB）无法通过 SQLite 原生支持，必须自行实现两阶段提交或改用服务端数据库；
- 过度拆分数据库可能增加维护复杂度、破坏数据一致性边界，并无助于提升单库高频写入瓶颈（如日志表高吞吐场景）；
- 官方明确建议：SQLite 适用于“低到中等写入负载”场景（
总结：分离数据到多个 SQLite 数据库可有效绕过单库写入瓶颈，是一种可行的轻量级水平扩展策略；但其本质是规避而非解决并发问题，不应作为高写入场景的长期架构方案。
