MySQL默认autocommit=1，每条DML自动提交不可回滚；确认状态用SELECT @@autocommit或SHOW VARIABLES LIKE 'autocommit'；关闭需SET autocommit = 0（仅当前会话），MyISAM引擎下无效，DDL语句仍会隐式提交。
autocommit 是 MySQL 控制事务行为的核心开关，它直接决定你写的每条 INSERT、UPDATE、DELETE 是否立刻生效且无法撤回。默认是开启的（@@autocommit = 1），但很多业务场景下必须关掉它，否则根本没法做原子性操作。
怎么快速确认当前会话的 autocommit 状态
最直接的方式是查变量值，不是看文档、不是猜配置，而是问 MySQL 自己：SELECT @@autocommit; —— 返回 1 就是开，0 就是关
或者用更传统的写法：SHOW VARIABLES LIKE 'autocommit';，结果里 Value 字段是 ON 或 OFF
- 注意：
@@autocommit查的是会话级变量，反映你当前连接的实际行为 -
SHOW GLOBAL VARIABLES LIKE 'autocommit'查的是全局设置，但它不影响已建立的连接，只影响新连接 - 有些 ORM（比如 Django 的
CONN_MAX_AGE复用连接）或连接池（如 HikariCP）可能在建连时就设定了autocommit=false，这时候查会话变量才真实
修改 autocommit 的三种常见方式及适用场景
改 autocommit 不是“一刀切”，得看你是临时调试、单次脚本，还是想让所有新连接都按需行为：
- 仅当前会话关闭：
SET autocommit = 0;—— 最常用，安全，断开重连即恢复默认 - 仅当前会话开启：
SET autocommit = 1;或SET autocommit = ON; - 全局修改（影响后续所有新连接）：
SET GLOBAL autocommit = 0;—— 需要SUPER权限，且服务重启后失效，除非写进my.cnf的[mysqld]段里加autocommit=0
⚠️ 别用 SET SESSION autocommit = OFF; 这种写法——语法合法但 MySQL 实际不认，它只接受 SET autocommit = 0 形式
autocommit = 0 后，为什么 UPDATE 还没提交却能被其他会话看到？
这不是 autocommit 的问题，而是事务隔离级别在起作用。即使 autocommit = 0，只要没 COMMIT，其他会话在默认的 REPEATABLE READ 隔离级别下，是看不到未提交变更的。
- 如果你发现“看到了”，大概率是：对方会话用了
READ UNCOMMITTED级别，或者执行了SELECT但没加任何事务控制，碰巧读到了刚改但未提交的数据（脏读） -
autocommit = 0只保证你自己的语句不自动提交，不改变其他会话的读行为 - DDL 语句（如
ALTER TABLE）哪怕在autocommit = 0下也会隐式触发COMMIT，这是 MySQL 硬规则，没法绕过
什么时候该关 autocommit，什么时候不该动它
关 autocommit 不是为了“看起来更专业”，而是解决具体问题：
- 需要多条 DML 组成原子操作（比如转账、库存扣减+订单生成）→ 必须关，然后配
START TRANSACTION+COMMIT/ROLLBACK - 只是跑一条
UPDATE调数据 → 开着更安全，省得忘了COMMIT导致长事务锁表 - 用的是 MyISAM 引擎 → 关了也没用，MyISAM 不支持事务，
autocommit设置无效（但不会报错） - 应用层已用框架管理事务（如 Spring 的
@Transactional）→ 别手动关，容易和框架冲突，让框架统一控制
真正容易被忽略的是：autocommit 关闭后，连接生命周期内会一直累积未提交变更，直到显式 COMMIT 或连接断开自动回滚。如果中间有长时间空闲或异常退出，可能留下孤立事务，影响并发性能。
