mysql中delete操作需手动commit当且仅当autocommit=0或处于显式事务中；默认autocommit=1时单条delete自动提交，而设为0后所有dml均需显式commit或rollback，否则连接中断将回滚。
autocommit=0 时执行 DML 不会自动提交，但很多人误以为“只要没 COMMIT 就安全”
这是最常被误解的点：设成 autocommit=0 后，INSERT/UPDATE/DELETE 确实不会自动提交，但事务仍处于活跃状态，连接断开、客户端崩溃或执行 START TRANSACTION（在某些版本中）都可能隐式提交当前事务。尤其要注意 MySQL 8.0.23+ 对 START TRANSACTION 的行为变更——它不再隐式提交，但 BEGIN 依然会。
实操建议：
- 显式用
START TRANSACTION或BEGIN开启事务，而非依赖 autocommit=0 的“默认事务” - 所有写操作后必须配对
COMMIT或ROLLBACK，不能靠连接关闭“侥幸提交” - 应用层连接池（如 HikariCP、Druid）默认重用连接，autocommit=0 的连接若未清理事务状态，下次复用时可能残留未提交数据
全局设置 autocommit=0 是危险操作，除非你完全掌控所有客户端行为
执行 SET GLOBAL autocommit = 0 会影响后续新建立的所有连接，但不会改变已有连接的状态。这意味着：已连上的监控工具、备份脚本、定时任务可能突然开始累积未提交事务，导致锁表、binlog 延迟、甚至 innodb_lock_wait_timeout 触发失败。
更现实的问题是权限和持久性：
-
SET GLOBAL需要SUPER权限（MySQL 8.0+ 改为SYSTEM_VARIABLES_ADMIN），生产环境通常禁用 - 该设置重启失效，若写入
my.cnf的autocommit=0，会导致所有客户端（包括mysql命令行、mysqldump）默认不自动提交，极易引发 dump 失败或交互式误操作 - ORM 框架（如 Django、SQLAlchemy）多数默认依赖 autocommit=1，设全局为 0 可能绕过其事务管理逻辑
连接级 autocommit 应该由应用代码控制，而不是靠配置文件硬编码
真正可控且安全的方式，是在获取数据库连接后立即执行 SET SESSION autocommit = 0（或 1），或者更推荐——让 ORM/驱动自己管理。例如：
- Python 的
pymysql初始化连接时可传autocommit=True参数；设为False后，所有 DML 都需手动commit() - Java JDBC URL 中加
?useSSL=false&autoReconnect=true&autocommit=false是常见做法，但注意：Spring@Transactional会覆盖此设置，实际以注解为准 - Node.js 的
mysql2默认 autocommit=1，调用connection.beginTransaction()才进入事务模式，无需提前关 autocommit
关键原则：autocommit 是连接会话属性，应随业务上下文动态设置，不是一劳永逸的服务器参数。
如何验证当前连接的 autocommit 状态？别只信配置文件
配置文件写的值 ≠ 当前连接生效值。运行中的连接可能被中间件、框架或之前 SQL 修改过。最可靠方式是查会话变量：
SELECT @@autocommit;
返回 1 表示开启，0 表示关闭。注意：
-
@@autocommit查的是 SESSION 级，@@@global.autocommit才是全局值（语法为SELECT @@global.autocommit） - 某些云数据库（如阿里云 RDS、AWS RDS）禁止修改全局 autocommit，但允许 SESSION 级设置
- 如果应用日志里出现
ERROR 1305 (42000): SAVEPOINT does not exist，往往是因为 autocommit=1 时误用了SAVEPOINT—— 它只在事务内有效
复杂点在于：autocommit 不是开关，而是事务边界的定义方式。它和 START TRANSACTION、SET TRANSACTION ISOLATION LEVEL、甚至隐式提交语句（如 ALTER TABLE）交织影响，调试时务必结合 SHOW ENGINE INNODB STATUS\G 看当前事务状态。
