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'。那个返回的是服务端配置，不是你当前连接的实际行为。
-
SELECT @@autocommit：返回整数1或0，才是当前会话真实开关状态 -
SELECT @@in_transaction：更关键——返回1才说明你正处在活跃事务里；哪怕@@autocommit = 0，执行完ALTER TABLE后它也会变0，意味着前面操作已隐式提交 - 生产环境排查“刚UPDATE查不到”“锁不释放”“连接卡住”，第一步永远是这两个查询，而不是翻配置文件或代码
连接池初始化时必须设 SET autocommit = 1
JDBC、PyMySQL、PDO 这些驱动建连后大概率会悄悄执行setAutoCommit(false)，哪怕 MySQL 服务端设了SET GLOBAL autocommit = 1，新连上来还是0。
- HikariCP：用
spring.datasource.hikari.connection-init-sql=SET autocommit = 1 - Druid：配
connectionInitSqls=["SET autocommit = 1"] - 别信
application.yml里的default-auto-commit: true，它不生效 - 临时在代码里执行
SET autocommit = 1？晚了——事务可能已经启了，@@in_transaction已是1，锁已经占着
START TRANSACTION 比 SET autocommit = 0 更安全
两者都能关自动提交，但语义和边界完全不同：
-
SET autocommit = 0会让后续所有 DML 累积进一个事务，直到你显式COMMIT或ROLLBACK——容易忘关，变成长事务，锁残留、连接堆积 -
START TRANSACTION是显式开启一个新事务，自带边界感：事务从这行开始，到COMMIT/ROLLBACK结束，之后自动恢复autocommit = 1（前提是连接没被污染） - DDL（如
ALTER TABLE）会隐式提交当前事务，不管autocommit值是多少——这点常被忽略，导致你以为还在事务里，其实早已提交
为什么不能设全局 autocommit = 0
设SET GLOBAL autocommit = 0看起来一劳永逸，但后果严重：
- 新连接上来仍是
autocommit = 1（全局变量不影响已有会话，也不强制新会话继承） - 部分客户端或 ORM 会主动覆盖该设置，你根本控制不了
- 一旦某处漏写
COMMIT，整个连接就卡在事务里，@@in_transaction = 1持续存在，锁不释放，别的会话查不到数据 - 真正可控的只有连接池初始化那一刻——把
SET autocommit = 1塞进 init-sql，确保每个连接干净起步
最易被忽略的点：@@in_transaction为1时，哪怕你没写START TRANSACTION，也可能是因为驱动偷偷关了autocommit，或者前一条语句触发了隐式提交但你没察觉。查状态，别猜。
