Python sqlite3 autocommit 与 isolation_level 怎么配合

我在把一段 Python 写入脚本迁移到新版本时，最容易混淆的不是 SQLite 语法，而是两个名字都带有 autocommit 的事务开关。结论先说：Python 3.12 及以上优先在 sqlite3.connect() 中设置 autocommit；只有维护旧项目或需要旧行为时，才围绕 isolation_level 设计隐式事务。两套方式不要同时当成主控制器。

官方文档：https://docs.python.org/3.13/library/sqlite3.html

一、先分清两种 autocommit 含义

Python 文档里有两个容易被混用的层次。连接对象的 autocommit 决定 Python 如何遵循 DB-API 事务规则；SQLite 底层的自动提交状态则可以通过只读属性 in_transaction 观察。前者是配置入口，后者是状态结果。

在 Python 3.12+ 中，autocommit 有三种选择：False 表示保持事务并显式提交，True 表示使用 SQLite 自动提交模式，sqlite3.LEGACY_TRANSACTION_CONTROL 表示把控制权交给旧的 isolation_level 逻辑。实际项目里，先选定一种模式，再写提交边界，排查会清楚很多。

二、Python 3.12+ 优先用 autocommit 控制事务

需要一组写操作要么全部成功、要么全部撤销时，推荐把 autocommit 设为 False，并在业务边界显式调用 commit()。这样提交动作出现在代码里，异常路径也能明确回滚。

import sqlite3

conn = sqlite3.connect("app.db", autocommit=False)
try:
    # 把同一批写入放在一个可回滚的事务边界内
    conn.execute("UPDATE account SET balance = balance - ? WHERE id = ?", (100, 1))
    conn.execute("UPDATE account SET balance = balance + ? WHERE id = ?", (100, 2))
    conn.commit()  # 两条更新都成功后再提交
except Exception:
    conn.rollback()  # 任一步失败都撤销本批修改
    raise
finally:
    conn.close()  # 无论成功或失败都释放连接

autocommit=True 适合每条语句可以独立落盘、并且不需要跨语句回滚的场景。这个模式下 commit() 和 rollback() 没有实际提交或撤销作用，所以不要一边选择 True，一边又把多条更新当成一个事务来理解。

三、旧项目用 isolation_level 时保持兼容

旧代码通常直接写 sqlite3.connect(path, isolation_level="DEFERRED")。在 legacy 模式下，DEFERRED、IMMEDIATE、EXCLUSIVE 对应不同的 SQLite BEGIN 行为，写入语句触发隐式事务，之后仍然需要 commit() 或 rollback()。

如果旧程序需要自己决定事务何时开始，可以把 isolation_level 设为 None，然后显式执行 SQL。这个写法让事务边界更直观，但也要求每条路径都认真处理失败情况：

conn = sqlite3.connect("app.db", isolation_level=None)
try:
    # None 不会自动 BEGIN，这里明确选择较早获取写锁的方式
    conn.execute("BEGIN IMMEDIATE")
    conn.execute("UPDATE settings SET value = ? WHERE name = ?", ("on", "feature"))
    conn.execute("COMMIT")  # 只有完成全部写入后才结束事务
except Exception:
    conn.execute("ROLLBACK")  # 显式事务失败时必须主动撤销
    raise
finally:
    conn.close()

四、用提交边界和 in_transaction 排查异常

遇到“代码执行成功但重启后数据没了”，先按三件事排查：连接创建时实际使用了哪种控制模式；写操作之后是否真的执行了提交；异常路径是否把连接关闭前的事务回滚了。in_transaction 可以作为观察点，但它只表示底层当前是否有未提交事务。

# 这个检查只观察状态，不代替 commit 或 rollback
print(conn.in_transaction)

还要留意 executescript() 的特殊行为：执行脚本前可能先提交待处理事务，因此不要把它和一组普通 execute() 调用混在同一个提交假设里。迁移时最稳妥的做法是先统一连接工厂，再逐个检查写入函数的提交边界。

相关问题

把 autocommit=False 和 isolation_level="DEFERRED" 一起传入可以吗？

可以传入但不应把两者都当作当前控制入口。autocommit 不是 legacy 值时，isolation_level 不生效；新代码直接围绕 autocommit 写提交和回滚更清楚。

isolation_level=None 是否代表每条 SQL 都自动提交？

它表示 Python 不再隐式开启事务，底层处于 SQLite 自动提交模式；如果手动执行 BEGIN，就必须手动配对 COMMIT 或 ROLLBACK。

为什么 commit() 后 in_transaction 仍可能变化？

在推荐的 Python 事务模式中，提交当前事务后连接可能立即准备下一个事务；因此应把 in_transaction 当状态观察值，不能据此猜测业务提交是否发生。