aiosqlite是SQLite异步操作的可行方案，其通过线程池封装实现伪异步，需开启WAL模式、批量事务、参数化查询、连接复用及超时控制以优化性能。
asyncio + aiosqlite 是唯一可行路径
SQLite 本身不支持真正的并发写入，但 Python 的 aiosqlite 库通过线程池 + 异步封装，让 await 调用看起来像异步操作。别试图用 asyncio.to_thread 包裹原生 sqlite3——它无法规避 SQLite 的串行化锁，反而增加调度开销，实际吞吐可能更差。
关键点在于：aiosqlite 并非“真异步驱动”，而是把每个数据库操作提交到单个后台线程池（默认 10 线程），所有 await conn.execute(...) 实际是排队等待线程空闲。所以「批量更新」的性能瓶颈不在 Python 协程层，而在 SQLite 的 WAL 模式配置和事务粒度。
必须开启 WAL 模式并手动控制事务
默认的 DELETE/INSERT 模式下，并发 UPDATE 会频繁触发写锁阻塞，aiosqlite 的协程只是在线程池外排队，毫无意义。WAL 模式允许读写并发，是异步批量更新的前提。
- 首次建库或连接时执行
await conn.execute("PRAGMA journal_mode = WAL") - 批量更新务必包裹在单个事务中：用
async with conn.transaction():，而不是对每条记录都await conn.execute(...) - 避免在事务内混用
SELECT和UPDATE——WAL 下读不阻塞，但某些查询仍可能触发检查点（checkpoint），拖慢写入
批量参数绑定要防 SQL 注入且兼顾性能
aiosqlite 支持 executemany()，但它在异步接口中需显式调用，且参数必须是列表而非生成器。直接拼接字符串或用 f-string 构造 SQL 是危险且低效的。
立即学习“Python免费学习笔记（深入）”；
正确做法：
await conn.executemany(
"UPDATE users SET status = ? WHERE id = ?",
[(new_status, user_id) for user_id in user_ids]
)
注意：
-
executemany()不返回行数，如需确认影响条数，得额外SELECT COUNT(*)或启用conn.row_factory - 参数列表超过 900 项时（SQLite 绑定参数上限），需分批，例如每 500 条一批
- 不要用
await conn.execute("UPDATE ... WHERE id IN ({})".format(...))—— 动态拼接IN列表既不安全，又易触发查询计划重编译
别忽略连接复用与超时设置
每次 aiosqlite.connect() 都会新建一个线程池实例，若在循环里反复创建连接，线程数爆炸，CPU 反而被调度器吃掉。同时，SQLite 的 WAL checkpoint 在高写入场景下可能卡住后续操作。
- 全局复用一个
aiosqlite.Connection对象，用async with conn.execute(...)确保语句级隔离 - 设置连接超时：传参
timeout=30.0，防止某次写入因锁争用永久挂起 - 定期触发检查点：在批量更新后执行
await conn.execute("PRAGMA wal_checkpoint(TRUNCATE)")，避免 WAL 文件无限增长
真正卡住的地方往往不是 await 本身，而是 WAL checkpoint 被其他连接阻塞，或者没设 timeout 导致协程永远等不到线程空闲。
