autocommit=1下单条insert慢主因是事务重复开销；显式事务（start transaction）可将千次操作压缩为一次提交，推荐统一使用以避免连接池残留事务风险。
autocommit=1 是默认行为，每条 INSERT 都会触发完整事务流程：写 redo log、刷盘、加锁、释放锁、更新索引。这不是“慢”，而是“重复做很多遍”。显式开启事务不是为了“加功能”，是为了避免这种高频开销。
为什么单条INSERT比批量INSERT慢一个数量级
关键不在 SQL 本身，而在事务生命周期的重复执行：
-
autocommit=1下，插入 1000 行 = 1000 次日志写入 + 1000 次刷盘（尤其当innodb_flush_log_at_trx_commit=1） - 行锁/间隙锁反复获取与释放，增加锁管理开销
- B+ 树索引页分裂被分散到每次插入，无法合并优化
- 网络往返次数翻倍（客户端每发一条，服务端回一个 OK）
而显式事务把这 1000 次压缩为一次提交：日志只刷一次、锁持有一次、索引变更批量合并。
START TRANSACTION 和 SET autocommit = 0 的区别
两者都能关闭自动提交，但行为细节不同：
-
START TRANSACTION或BEGIN显式开启新事务，会清空当前连接中可能残留的未提交状态 -
SET autocommit = 0只是关掉自动提交开关，不隐式开启事务；后续第一条 DML（如INSERT）才真正启动事务 - 在连接池场景下，
SET autocommit = 0更危险——若上一个使用者没COMMIT或ROLLBACK，当前请求会继承未结束事务，导致静默阻塞
推荐统一用 START TRANSACTION 开头，COMMIT 或 ROLLBACK 结尾，边界清晰。
事务大小怎么定：500 行还是 5000 行？
没有固定值，取决于三个现实约束：
-
max_allowed_packet限制单条语句长度（默认 4MB），多值INSERT INTO t VALUES (),()...超长会被截断或报错 - 事务越长，
undo log占用越多，主从延迟越明显，且ROLLBACK恢复时间越长 - 有唯一索引时，大事务失败后回滚代价高；冲突率高的场景（如频繁重试插入），建议缩小批次
实测经验：平均行宽 ≤ 200 字节时，1000–2000 行/事务较稳；若含大字段（TEXT/BLOB），压到 500 行以内更安全。
容易被忽略的性能陷阱
事务快的前提是“干净”和“可控”，但很多人踩在这些点上：
- 在事务里混
SELECT—— 尤其是查大表或带子查询的，会让整个事务变成串行瓶颈 - 忘记
COMMIT，连接复用后下个请求卡在旧事务里，表现为“莫名锁表”或“查询变慢” - 用字符串拼接构造超长
INSERT，应用内存爆掉或 MySQL 中断连接，错误信息常是Packets larger than max_allowed_packet are not allowed - 误以为
LOCK TABLES或SELECT FOR UPDATE能加速插入——实际会扩大锁范围、引发死锁，纯属负优化
真正该调的不是锁，是 innodb_log_file_size、innodb_buffer_pool_size 和 innodb_flush_log_at_trx_commit。事务只是第一层杠杆，底层配置没跟上，效果会迅速见顶。
