Python sqlite3 blob 写入后怎样控制事务提交

Python sqlite3 用 Blob 写入后，应先关闭 Blob 句柄，再提交它所属连接的事务。要让多个分块作为一个整体保存，可以显式采用 autocommit=False：分块全部写完并退出 Blob 上下文后调用 con.commit()，任何写入或提交异常则回滚。不要把一次 blob.write() 或句柄关闭当成统一的事务提交指令。

官方地址：https://docs.python.org/3.14/library/sqlite3.html

基线：先数提交边界，再讨论性能

假设一个对象由两个 4 字节分块组成。我们关心的是八个字节是否一起成功，而不是哪个 write 先返回。本文示例的对象写入路径有两次 Blob.write 和一次显式 commit；初始化表结构另有一次 commit，单独计算。这些是代码结构中的调用次数，不是磁盘同步次数或压测数据。

可提出一个工程假设：把同一对象的分块放进一个事务，可以减少应用层人为拆分的提交边界，并保留对象级原子性。但它是否更快、快多少，需要在相同存储与配置下测量，不能仅凭 write 次数推导吞吐提升。

改动点：固定事务模式，再把提交放到句柄范围外

blobopen 从 Python 3.11 提供；本例还使用 Python 3.12 新增的 autocommit 参数，因此要求 Python 3.12 或以上。显式传入模式，可以避免把不同版本的默认事务行为混在一起。

import sqlite3
from contextlib import closing

def store_chunks(db_path, chunks):
    # 演示使用已在内存中的 bytes 分块，长度按字节计算。
    total_size = sum(len(part) for part in chunks)
    with closing(sqlite3.connect(db_path, autocommit=False)) as con:
        con.execute(
            "CREATE TABLE IF NOT EXISTS objects "
            "(id INTEGER PRIMARY KEY, payload BLOB NOT NULL)"
        )
        con.commit()  # 单独提交初始化结构，不计入对象写入事务。

        try:
            cursor = con.execute(
                "INSERT INTO objects(payload) VALUES (zeroblob(?))",
                (total_size,),
            )
            rowid = cursor.lastrowid
            cursor.close()
            # 内层只管理 Blob 句柄，退出时并不替外层提交。
            with con.blobopen("objects", "payload", rowid) as blob:
                for part in chunks:
                    blob.write(part)
            # 确认句柄已经关闭，再提交整个对象。
            con.commit()
            return rowid
        except BaseException:
            # 包括写入和提交失败：回滚后继续传播异常。
            con.rollback()
            raise

# Python 3.12+：两个分块属于同一个对象写入事务。
object_id = store_chunks("objects.db", [b"ABCD", b"EFGH"])
print(object_id)

这里先插入一个固定长度的 zeroblob，再用新行的 rowid 打开 payload。调用方提供 bytes 分块，因此 len 的单位就是字节。内层 with 只负责 Blob；外层 closing 负责连接。函数只在 commit 成功后返回对象 ID，不让“分块写完”提前变成业务成功。

异常处理覆盖写入与最终提交，包括块长度超出预分配范围等失败。Blob 的上下文会先退出，然后才进入回滚分支；异常继续向调用方传播。实际系统若连 rollback 本身也失败，应保留原始错误与清理错误并丢弃连接，不能报告保存成功。

对照方法：分开观察写入、关闭与提交耗时

如果需要比较策略，至少保持对象大小、分块大小、日志模式、同步配置、数据库位置和其他连接负载一致。可以分别记录 write 总耗时、Blob 关闭耗时、commit 耗时及失败次数，尤其不要只计量循环写入，然后把最终提交成本排除在“保存耗时”之外。

原子性场景也应独立设计：在中间块失败、句柄关闭失败或提交失败时，业务应返回错误，未提交对象不应被当作完成对象使用。重新读取结果应使用明确的事务与可见性边界；同一连接能够读取自己尚未提交的修改，不能用这个现象证明提交完成。这里给出的是应用侧对照设计，没有执行压测或宣称测量结论。

结果对比：关闭句柄、结束事务、释放连接各做什么

SQLite 把打开的增量 Blob 句柄视作尚未结束的语句。保持可写句柄打开就尝试提交，可能因为待完成写操作而失败。先关闭句柄是提交准备的一部分，但关闭后是否提交仍由事务模式决定。

在底层 SQLite 自动提交模式下，关闭最后一个可写 Blob，且没有其他活动写操作时，确实可能触发隐式提交。这正是不能把“关闭一定提交”或“关闭绝不会提交”当成普遍规则的原因。本文为了控制一个完整对象的边界，固定使用显式管理事务的模式。

边界条件：长度、模式和锁竞争都不能省略

Blob.write 不会扩展 BLOB 长度，超过末尾会抛出 ValueError。未知长度的流不能直接套用“先 sum 再写”的内存示例；可以先获得可靠长度、使用临时存储，或者改成多行分块模型，并重新设计完成标记与提交策略。分块大小改变的是访问方式，不自动改变事务边界。

不要在 autocommit=True 下照搬 commit/rollback 方案，Python 文档明确这两个方法在该模式下不起作用。旧项目若使用 LEGACY_TRANSACTION_CONTROL，行为又受 isolation_level 影响；迁移时应先选定一种控制方式，不把自动 BEGIN、手写 BEGIN 与不同 autocommit 模式随意叠加。

autocommit=False 会在 commit 或 rollback 后建立新的事务，因此不能要求 commit 之后 in_transaction 必须为 false 才算成功。该属性描述底层事务状态，不是“刚才那个对象是否保存成功”的独立凭据。

SQLite 同时只允许一个写事务。单个对象很大、处理过程中又夹带网络等待时，会延长写事务占用。应尽量先准备可写数据，再进入需要原子写入的范围；遇到锁竞争，结合错误与剩余事务状态决定回滚或受控重试，不要在尚未关闭的 Blob 上盲目反复 commit。

相关问题

with con 会自动关闭连接吗

不会。连接上下文管理事务的提交或回滚，不负责关闭连接。本例用 closing 处理连接资源，也可以采用明确的 finally 关闭。

能否每写一块就提交一次

不应在一个仍打开的可写句柄上这样操作。即便重新打开并为每块建立独立事务，也会失去完整对象一次成功或一次回滚的语义；如果确实需要断点续写，应为分块状态单独建模。

Blob 可以用于 WITHOUT ROWID 表吗

Python blobopen 对这类表会报 OperationalError。本文使用 INTEGER PRIMARY KEY 的普通 rowid 表，并使用实际插入行 ID 打开句柄。

参考资料

• Python sqlite3：Blob 与事务控制
• SQLite：关闭 Blob 句柄的自动提交条件
• SQLite：事务、未完成语句和写锁