sqlite3 autocommit怎么配置或排查

Python 的 sqlite3 事务问题，通常不是“SQLite 没有提交”，而是把 Python 的事务控制、底层 SQLite 的 autocommit 状态和旧版 isolation_level 混在了一起。Python 3.12 及以上优先在 connect() 中明确传入 autocommit；需要批量写入时用 False 配合 commit()，只想让每条语句独立落盘时才用 True。

官方资料：https://docs.python.org/3/library/sqlite3.html

排查时先看 con.autocommit、con.isolation_level 和 con.in_transaction，再用“写入—提交或回滚—关闭—重连查询”验证。不要只看一次查询结果就判断事务已经生效。

先把 sqlite3 的三种提交模式分清

当前文档把 Connection.autocommit 作为推荐入口。False 表示按 DB-API 事务方式工作，连接会保持一个打开的事务，业务在合适的位置调用 commit() 或 rollback()。True 则启用 SQLite 的自动提交模式，每条完成的写语句可以独立提交，调用提交和回滚方法不会替你撤销已经完成的写入。

第三个值是 sqlite3.LEGACY_TRANSACTION_CONTROL。它把控制权交给旧式的 isolation_level，便于维护历史代码，但不适合新代码继续“默认猜测”。

Python 3.12 以上怎么配置并验证

新项目建议在连接时写出模式，不要依赖默认值。下面的示例把两条写入放在同一个事务里，第二条故意抛出异常，结果应当整体回滚；注释只解释关键的提交边界。

import sqlite3

con = sqlite3.connect(":memory:", autocommit=False)
try:
    # 建表属于本次演示的初始化动作。
    con.execute("CREATE TABLE account (id INTEGER PRIMARY KEY, balance INTEGER NOT NULL)")
    # 两条写入共享一个事务，任一条失败都不应留下半套数据。
    con.execute("INSERT INTO account(balance) VALUES (?)", (100,))
    con.execute("INSERT INTO account(balance) VALUES (?)", (200,))
    con.commit()  # 只有走到这里，事务内写入才正式提交。
except sqlite3.Error:
    con.rollback()  # 发生数据库错误时撤销本轮未提交的变化。
    raise
finally:
    con.close()  # 关闭连接，避免把连接生命周期当成提交动作。

若要排查配置，连接创建后先打印三个状态：

# 这些属性分别表示 Python 控制模式、旧式参数和底层事务状态。
print(con.autocommit)
print(con.isolation_level)
print(con.in_transaction)

in_transaction=True 说明底层 SQLite 当前有未提交变化；它不是“Python 是否设置了自动提交”的同义词。验证持久化时，应在提交或回滚后关闭连接，再开一个新连接查询。

isolation_level 不生效时按版本排查

如果代码使用 autocommit=False 或 True，isolation_level 不再负责事务控制，这是最常见的“我设置了却没变化”原因。只有处于 legacy 模式时，"DEFERRED"、"IMMEDIATE" 和 "EXCLUSIVE" 才会影响隐式开启事务的方式。

Python 3.11 及更早版本没有新的 autocommit 连接参数。若目标是底层 SQLite 自动提交，可使用 isolation_level=None；若要一组语句一起提交，则保留默认的隐式事务行为，并在业务边界显式调用 commit()：

import sqlite3

# 旧版本中 None 表示不自动开启隐式事务，SQL 可自行写 BEGIN/COMMIT。
con = sqlite3.connect("demo.db", isolation_level=None)
try:
    con.execute("BEGIN IMMEDIATE")  # 明确声明本次写事务的开始。
    con.execute("UPDATE account SET balance = balance - ? WHERE id = ?", (10, 1))
    con.execute("COMMIT")  # 与 BEGIN 配对，成功后才让修改对外可见。
except sqlite3.Error:
    con.execute("ROLLBACK")  # 手动事务失败时必须显式回滚。
    raise
finally:
    con.close()

不要把 isolation_level=None 和“所有调用都有事务保护”画等号：它只是关闭 Python 的隐式开启，事务边界要由你的 SQL 或其他代码自己负责。

四个容易误判的边界

第一，executescript() 在执行脚本前会处理待提交事务，不能把它当作普通的多次 execute()。第二，连接关闭时仍有待提交变化，不应当被当作可靠的提交动作；需要保存就先显式 commit()。第三，rollback() 只能影响当前仍未提交的事务，自动提交模式下它没有撤销已完成语句的能力。第四，DDL 不等于事务测试，最好用一条可查询的 INSERT 或 UPDATE，重连后再确认结果。

实际排障可以按这个顺序走：确认 Python 版本；记录连接创建时的 autocommit 或 isolation_level；在写入前后观察 in_transaction；明确调用提交或回滚；最后用新连接查询。这样能快速区分“参数未生效”“事务尚未结束”和“结果已经提交”三类问题。

常见问题

autocommit=True 还能调用 commit() 吗？

可以调用，但当前模式下它没有提交待处理事务的作用；如果业务需要成组回滚，应改用 autocommit=False。

为什么 isolation_level=None 后 rollback 没效果？

因为此时通常没有由 Python 隐式开启的事务。要获得回滚能力，需要显式执行 BEGIN，并在异常路径执行 ROLLBACK。

如何判断数据真的写进数据库？

在明确 commit() 后关闭连接，再建立新连接查询；不要只在原连接里查询，因为原连接可能仍看得到自己的未提交变化。