生产环境中@@autocommit常被驱动或连接池默认设为0，须用select @@autocommit和select @@in_transaction实时验证；start transaction比set autocommit=0更安全，ddl会隐式提交事务，导致rollback仅回滚其后操作。
别信“默认是1”——生产环境里@@autocommit几乎总是被驱动或连接池悄悄改成0，不查就踩坑。
查当前连接的真实 autocommit 状态
文档说默认开，但你连上的那个会话未必是1。不同驱动（JDBC/PyMySQL/PDO）、不同连接池（HikariCP/Druid）、甚至同个客户端不同版本，都可能在建连后自动执行setAutoCommit(false)，把@@autocommit设成0。
必须现场查：
-
SELECT @@autocommit;—— 返回1才真开，0就是关 -
SELECT @@in_transaction;—— 更关键：返回1说明你正处在活跃事务里；哪怕@@autocommit=0，执行完ALTER TABLE后它也会变0，意味着前面操作已隐式提交
排查“刚UPDATE查不到”“锁卡住”“连接挂起”，第一步永远是这两个查询，不是翻配置文件。
连接池初始化时必须设 SET autocommit = 1
靠应用代码里临时执行SET autocommit = 1没用——事务可能已经启了，锁已经占着，数据已经不可见。
正确做法是在连接池创建连接时就强制初始化：
- HikariCP：
spring.datasource.hikari.connection-init-sql=SET autocommit = 1 - Druid：
connectionInitSqls=["SET autocommit = 1"] - MyBatis + Spring Boot：走 Hikari 配置项，别信
application.yml里的default-auto-commit: true，它不生效
不配connection-init-sql的后果：单条UPDATE执行完，别的会话查不到，锁还占着，SELECT @@in_transaction是1，但你根本没写START TRANSACTION——就是驱动干的。
START TRANSACTION 比 SET autocommit = 0 更安全
两者都能关自动提交，但语义和边界完全不同：
-
SET autocommit = 0是会话级开关，之后所有 DML 都进同一个事务，直到你显式COMMIT或ROLLBACK，容易漏掉提交导致长事务、锁堆积 -
START TRANSACTION是显式事务起点，执行后@@autocommit临时变为0，COMMIT或ROLLBACK后自动恢复为1，边界清晰、不易遗漏
DDL（如ALTER TABLE）会隐式提交当前事务，哪怕@@autocommit=0也一样——这点常被忽略，导致后续DML意外脱离原事务。
autocommit=0 时 DDL 会偷偷提交事务
这是最容易被忽视的陷阱：哪怕你明确SET autocommit = 0并开了事务，只要中间执行一条CREATE、ALTER或DROP，MySQL 就会立刻隐式执行COMMIT，把你前面所有未提交的 DML 一起刷出去。
后果很隐蔽：
- 你以为还在一个事务里，其实早被切开了
-
ROLLBACK只能回滚 DDL 之后的操作，前面的改写已永久生效 - 锁提前释放，但数据状态已不一致
所以关键业务中，DML 和 DDL 必须拆开执行，且 DDL 前确认@@in_transaction = 0，否则事务控制就失效了。
