如何理解MySQL自动提交模式并正确设置

MySQL自动提交真实状态需查SELECT @@autocommit和SELECT @@in_transaction确认，前者返回1/0表示当前会话开关，后者为1才表明正处活跃事务；连接池初始化时必须显式执行SET autocommit = 1，且START TRANSACTION比SET autocommit = 0更安全可控。

MySQL自动提交模式不是“开或关”那么简单——它实际生效状态必须查SELECT @@autocommit和SELECT @@in_transaction确认，否则你写的SET autocommit = 1可能早被连接池或驱动覆盖了。

查当前连接的真实 autocommit 和事务状态

别信文档说“默认是1”，也别只看SHOW VARIABLES LIKE 'autocommit'。那个返回的是服务端配置，不是你当前连接的实际行为。

1. SELECT @@autocommit：返回整数1或0，才是当前会话真实开关状态
2. SELECT @@in_transaction：更关键——返回1才说明你正处在活跃事务里；哪怕@@autocommit = 0，执行完ALTER TABLE后它也会变0，意味着前面操作已隐式提交
3. 生产环境排查“刚UPDATE查不到”“锁不释放”“连接卡住”，第一步永远是这两个查询，而不是翻配置文件或代码

连接池初始化时必须设 SET autocommit = 1

JDBC、PyMySQL、PDO 这些驱动建连后大概率会悄悄执行setAutoCommit(false)，哪怕 MySQL 服务端设了SET GLOBAL autocommit = 1，新连上来还是0。

1. HikariCP：用spring.datasource.hikari.connection-init-sql=SET autocommit = 1
2. Druid：配connectionInitSqls=["SET autocommit = 1"]
3. 别信application.yml里的default-auto-commit: true，它不生效
4. 临时在代码里执行SET autocommit = 1？晚了——事务可能已经启了，@@in_transaction已是1，锁已经占着

START TRANSACTION 比 SET autocommit = 0 更安全

两者都能关自动提交，但语义和边界完全不同：

1. SET autocommit = 0会让后续所有 DML 累积进一个事务，直到你显式COMMIT或ROLLBACK——容易忘关，变成长事务，锁残留、连接堆积
2. START TRANSACTION是显式开启一个新事务，自带边界感：事务从这行开始，到COMMIT/ROLLBACK结束，之后自动恢复autocommit = 1（前提是连接没被污染）
3. DDL（如ALTER TABLE）会隐式提交当前事务，不管autocommit值是多少——这点常被忽略，导致你以为还在事务里，其实早已提交

为什么不能设全局 autocommit = 0

设SET GLOBAL autocommit = 0看起来一劳永逸，但后果严重：

1. 新连接上来仍是autocommit = 1（全局变量不影响已有会话，也不强制新会话继承）
2. 部分客户端或 ORM 会主动覆盖该设置，你根本控制不了
3. 一旦某处漏写COMMIT，整个连接就卡在事务里，@@in_transaction = 1持续存在，锁不释放，别的会话查不到数据
4. 真正可控的只有连接池初始化那一刻——把SET autocommit = 1塞进 init-sql，确保每个连接干净起步

最易被忽略的点：@@in_transaction为1时，哪怕你没写START TRANSACTION，也可能是因为驱动偷偷关了autocommit，或者前一条语句触发了隐式提交但你没察觉。查状态，别猜。