Python sqlite3 批量写入怎么控制提交和回滚

Python 用 sqlite3 批量写入时，提交和回滚不是由 executemany() 单独决定的，而是由事务边界决定。要让一批数据“要么全部写入，要么一行都不落盘”，把所有写操作放进同一个连接事务；要控制内存或锁持有时间，再把数据切成多个批次，并接受“已经提交的批次不能整体回滚”这个结果。

先把事务边界放在批量写入外面

先决定业务需要哪一种结果：导入订单明细、配置快照这类数据通常要求整批原子性；日志、采集记录则可能允许前几批先保存。这个选择比“循环里每行调用一次 commit()”更重要，因为每次提交都会结束当前事务，后面发生异常时只能回滚尚未提交的部分。

在 Python 3.12 及以后，可以在连接时明确使用 PEP 249 风格的事务控制。连接对象负责承载事务，executemany() 负责按参数序列执行同一条写入语句，commit() 和 rollback() 则决定待提交变更的去留。

用 Connection 上下文管理器处理整批提交

整批写入最清楚的写法是让连接对象包住写入代码。代码块正常结束时，连接上下文管理器提交当前事务；代码块中抛出未捕获异常，事务回滚，异常仍然会继续向外抛出，所以外层可以记录失败原因。

import sqlite3

rows = [("alice", 18), ("bob", 21), ("carol", 20)]

con = sqlite3.connect("members.db", autocommit=False)
try:
    con.execute("""
        CREATE TABLE IF NOT EXISTS member(
            name TEXT PRIMARY KEY,
            age INTEGER NOT NULL
        )
    """)
    with con:
        # 同一个 with 块内的多行写入属于同一批事务
        con.executemany(
            "INSERT INTO member(name, age) VALUES (?, ?)",
            rows,
        )
        # 不在循环里手动 commit，让上下文管理器统一决定结果
finally:
    # 连接上下文管理器只负责事务，不负责关闭连接
    con.close()

如果 rows 中出现重复主键，IntegrityError 会使这次 with con: 回滚，前面已经执行的插入也不会单独留下。这里的前提是这些写操作确实使用同一个连接，并且没有在块内提前提交。

需要分批提交时，把回滚范围写清楚

数据量较大时，可以按固定大小切片。每个批次成功后提交；某个批次失败时调用 rollback()，它只能撤销本次提交之后仍处于打开状态的事务。若想在一个大事务内部试写一小段，可以使用 SQLite 的 SAVEPOINT，但保存点回滚也不会抹掉已经完成的外层提交。

import sqlite3

def chunks(items, size):
    for start in range(0, len(items), size):
        # 切片边界就是本文选择的提交边界
        yield start, items[start:start + size]

con = sqlite3.connect("members.db", autocommit=False)
try:
    for start, batch in chunks(rows, 100):
        try:
            # 当前批次单独使用一个保存点，便于定位哪一批失败
            con.execute("SAVEPOINT import_batch")
            con.executemany(
                "INSERT INTO member(name, age) VALUES (?, ?)",
                batch,
            )
            con.execute("RELEASE SAVEPOINT import_batch")
            con.commit()  # 这一批成功后，前一批也不能再整体回滚
        except sqlite3.IntegrityError as exc:
            con.execute("ROLLBACK TO SAVEPOINT import_batch")
            con.execute("RELEASE SAVEPOINT import_batch")
            con.rollback()  # 放弃当前事务里的未提交变更
            print(f"第 {start} 行附近的批次失败：{exc}")
            break
finally:
    con.close()

如果业务要求“任何一批失败都清空全部导入”，就不要在循环中提交，而应把所有批次放在一个外层事务里，失败时只调用一次 rollback()。分批提交换来的是更小的回滚范围和更容易恢复的进度，不是全局原子性。

检查 autocommit、关闭连接和验证结果

调试时可以检查 con.in_transaction，确认当前是否仍有未提交事务。还要注意，executescript() 有自己的事务边界行为，不要把它和 executemany() 的行为混在一起。最终验证不要只看内存里的列表：提交后重新执行带条件的 SELECT COUNT(*)，并把成功批次范围写入日志，后续重试才不会重复导入。

常见问题

executemany() 会自动提交吗？

不会把“提交策略”替你决定。它执行参数序列，提交仍由连接事务控制；应在合适的批次边界调用 commit()，或交给连接上下文管理器。

rollback() 为什么没有删除已经插入的前几批？

因为前几批已经调用过 commit()。回滚只作用于当前仍未提交的事务，想要全有或全无就必须延后最终提交。

with con: 结束后还需要 close() 吗？

需要。连接上下文管理器只提交或回滚事务，不会关闭连接；用完后显式调用 close()，或把连接生命周期交给更外层的关闭管理器。