autocommit默认开启不拖慢性能，但高频小事务因每次DML都触发redo log fsync而显著降低性能；正确批量操作需SET autocommit=0配合START TRANSACTION显式包裹，并调整innodb_flush_log_at_trx_commit。
Autocommit 默认开启本身不拖慢性能，但高频小事务会显著增加 fsync 开销
autocommit=1 时每条 DML 都触发一次 redo log 刷盘
InnoDB 在 autocommit=1 下，每个 INSERT/UPDATE/DELETE 都是独立事务，必须保证 redo log 持久化（即调用 fsync）后才算提交成功。这意味着：插入 1000 行数据 = 1000 次磁盘刷盘（除非使用 group commit 且并发高）。而 fsync 是阻塞式系统调用，在机械盘或未优化的 SSD 上耗时明显。
- 即使语句很快返回，实际延迟常被
fsync占据大头 - binlog 也会同步刷盘（如果启用了
sync_binlog=1），形成双重开销 - MyISAM 表不受影响——它压根不写 redo log，autocommit 设置对它无意义
关闭 autocommit 后必须显式用 START TRANSACTION 才能合并事务
只执行 SET autocommit=0 不等于“开启批量事务”。它只是把后续每条 DML 变成隐式事务单元，仍各自持锁、各自生成事务 ID、各自在语句结束时尝试提交（但因 autocommit 关闭而挂起）——这反而更糟：锁持有时间拉长、MVCC 版本链膨胀、容易被 kill 导致连接残留。
- 正确做法是：先
SET autocommit=0，再用START TRANSACTION显式开启一个事务块 - 所有 DML 写在
START TRANSACTION和COMMIT之间，redo log 只在COMMIT时刷一次（或由 group commit 批量处理） - 漏写
START TRANSACTION是最常见错误，此时你以为在批量操作，其实仍在挨个刷盘
innodb_flush_log_at_trx_commit=1 是默认值，也是性能关键开关
这个参数决定事务提交时 redo log 的刷盘策略：1（默认）= 每次 COMMIT 都 fsync；0 = 每秒刷一次；2 = 每次 COMMIT 写入 OS 缓存，不 fsync。它和 autocommit 是正交关系——哪怕你用 START TRANSACTION 包了 100 条语句，只要 innodb_flush_log_at_trx_commit=1，COMMIT 还是会强制刷盘。
- 想真正减少刷盘次数，必须同时满足两个条件：显式事务 +
innodb_flush_log_at_trx_commit调整（注意：设为 0 或 2 会牺牲部分持久性） - 连接池配置（如 HikariCP 的
connection-init-sql）若只设SET autocommit=0，没跟START TRANSACTION，照样白搭 - DDL 语句（如
ALTER TABLE）会隐式触发COMMIT，打断当前事务，这点极易被忽略
真正影响性能的不是 autocommit 开关本身，而是你是否理解「事务边界」与「日志刷盘时机」的绑定关系。没用 START TRANSACTION 包裹操作，关了 autocommit 只会让问题更隐蔽——锁更久、回滚段更大、监控指标更难归因。
