Python sqlite3.Blob 怎么改大字段：blobopen、固定长度与事务边界

把用户头像、压缩附件或者小型模型片段存在 SQLite 里的时候，要是直接把整段 bytes 全读出来再覆盖写回去，代码看起来虽然短，实际跑起来内存峰值和事务边界特别容易出问题。Python 的 sqlite3.Connection.blobopen() 提供了按表、列和 rowid 直接打开 BLOB 的入口，但它不会自动扩容，后续写入的总长度必须提前由 zeroblob() 或者单元格里已有的值确定。

要更新 SQLite 的大字段，先用 zeroblob(N) 预留固定长度，再通过 blobopen(table, column, rowid, readonly=False) 分块写入；写完关闭 Blob，最后由连接提交事务。长度不匹配、rowid 不存在和提前提交，都是最常见的失败点。

一次失败的头像替换，暴露了三个边界

一个本地资料服务把头像存进 user_assets.avatar。最初写的替换函数是 UPDATE user_assets SET avatar=?，测试用的小图片只有几十 KB 时完全没问题；换成 8 MB 的原图之后，进程内存短时翻倍，上传中断还留下了半截无效的业务记录。

排查之后发现根本原因不是“SQLite 不能存大字段”。真正要拆分清楚的是三个动作：字段是否已经预留了足够空间、写入游标是否落在正确位置、事务有没有在资源关闭前提前提交。Blob 对象只解决第二个动作。

blobopen() 打开的到底是什么

官方接口的核心参数是表名、列名和整数 rowid。下面先建一张最小测试表，并用 zeroblob() 预留 12 字节。这里的长度只是示例用的，生产代码要根据实际文件大小或者协议上限计算。

import sqlite3

con = sqlite3.connect("assets.db")
con.execute("DROP TABLE IF EXISTS user_assets")
con.execute("CREATE TABLE user_assets (id INTEGER PRIMARY KEY, avatar BLOB NOT NULL)")
con.execute("INSERT INTO user_assets (avatar) VALUES (zeroblob(?))", (12,))
rowid = con.execute("SELECT last_insert_rowid()").fetchone()[0]
con.commit()

blob = con.blobopen("user_assets", "avatar", rowid, readonly=False)
try:
    blob.write(b"hello-python")
finally:
    blob.close()
con.commit()

blobopen() 返回的是支持读写的类文件对象。它有 read()、write()、seek() 和 tell() 等操作，但不像普通本地文件那样可以把 12 字节的内容直接写成 13 字节。Blob 可写入的总长度从打开的那一刻起，就由对应的 SQLite 单元格的长度决定了。

固定长度写入：先算大小，再分块落盘

如果数据来自上传流，别先把整个文件全读到内存里拼成一个 bytes。可以先拿到数据总大小，插入 zeroblob(size)，然后每次读取 64 KiB 往 Blob 里写。下面示例用内存流模拟上传场景，换成真实磁盘文件的时候替换掉 source.read 就行。

import io
import sqlite3

def write_blob(con: sqlite3.Connection, source: io.BufferedReader, size: int) -> int:
    cur = con.execute(
        "INSERT INTO user_assets (avatar) VALUES (zeroblob(?)) RETURNING id",
        (size,),
    )
    rowid = cur.fetchone()[0]
    written = 0
    blob = con.blobopen("user_assets", "avatar", rowid, readonly=False)
    try:
        while chunk := source.read(64 * 1024):
            if written + len(chunk) > size:
                raise ValueError("source is larger than reserved BLOB")
            blob.write(chunk)
            written += len(chunk)
        if written != size:
            raise ValueError(f"source size mismatch: {written} != {size}")
    except Exception:
        con.rollback()
        raise
    finally:
        blob.close()
    con.commit()
    return rowid

payload = b"python-blob-demo"
with sqlite3.connect(":memory:") as con:
    con.execute("CREATE TABLE user_assets (id INTEGER PRIMARY KEY, avatar BLOB NOT NULL)")
    rowid = write_blob(con, io.BytesIO(payload), len(payload))
    print(rowid, con.execute("SELECT length(avatar) FROM user_assets").fetchone()[0])

这个函数对“预留长度”和“实际写入长度”都做了校验。如果源数据提前结束，回滚动作会直接撤销刚插入的行；如果源数据超出预留长度，异常会在下一次写入前触发，不会出现数据被静默截断的情况。

事务和资源关闭顺序，决定失败后留下什么

Blob 是数据库连接上的依附资源，连接关闭之前最好显式把 Blob 关掉。更新完成后先关闭 Blob，再提交连接，后续代码逻辑排查起来也更清晰。针对已有记录的更新操作，建议把 blobopen() 放在一个小事务里执行，避免长时间持有数据库写锁。

还有一个很容易被忽略的点：如果打开 Blob 之后，对同一连接执行了影响它所在行的结构修改操作，资源状态就会变得很难预判。别把 DDL、长查询和网络等待逻辑放到 Blob 写入的事务里；写入、关闭、提交这几个动作尽量连续完成。

已有 BLOB 的局部修改怎么做

固定长度特性也适合做局部更新。比如头像文件头部有一段可以修正的元数据，可以先以只读方式确认总长度，再以读写方式定位到指定偏移位置修改。seek() 的偏移是字节位置，不是字符位置。

with sqlite3.connect("assets.db") as con:
    rowid = 7
    size = con.execute(
        "SELECT length(avatar) FROM user_assets WHERE id=?", (rowid,)
    ).fetchone()[0]
    if size is None or size 

这里的 with sqlite3.connect(...) 会在代码块正常结束时提交事务，异常时自动回滚；它不会替代 Blob 的关闭动作，所以代码里依然保留了 try/finally。

常见误区与回归清单

• 把 blobopen() 当成支持自动扩容的普通文件：需要改变总长度的时候，重新写入新的 BLOB 内容或者先重新预留对应空间。
• 只检查 Python 侧变量的长度：还要在新的数据库连接里查询 length(column)，确认提交动作真的生效了。
• 在 Blob 打开期间等待网络上传：应该先把输入数据准备好再操作，或者用短事务处理，避免长时间占用写锁。
• 用文本字符数计算二进制长度：BLOB 的长度是按字节计算的。

相关问题

blobopen() 能打开 NULL 值吗？

不能把 NULL 当成可写的固定长度 BLOB 使用。先用 zeroblob(N) 或者写入实际的 BLOB 占位内容，再打开目标行操作。

写入失败后是否必须手动 rollback？

如果事务是由连接上下文或者显式事务管理的，异常路径要执行回滚；关闭 Blob 只释放资源，不会自动撤销已经执行的 SQL 操作。

什么时候不适合用 Blob？

文件体积很大、需要对象存储能力或者多个进程频繁并发读写的时候，可以评估把文件直接放在文件夹或对象存储里，SQLite 只保存存储路径、摘要和元数据。

结语：把 BLOB 当成固定长度事务资源

sqlite3.Blob 适合在 SQLite 内对已定位的二进制单元做分块读写。稳定的实现逻辑一般遵循四步：先用 zeroblob 预留对应长度，按字节流写入内容，finally 关闭 Blob，最后提交事务并重新查询长度做校验。把这四步补充到测试用例里，剩下的就可以根据文件规模和并发模型，判断当前场景下 SQLite 是否依然是合适的选择。