在MySQL中如何使用事务包裹多条DML实现原子提交？-mysql教程-PHP中文网

mysql事务需显式开启，start transaction或begin均可；自动提交默认开启，必须关闭才能多语句事务；commit成功不保证落盘，依赖innodb_flush_log_at_trx_commit配置；错误不自动回滚，需应用层捕获并rollback；长事务影响mvcc清理与性能。

在mysql中如何使用事务包裹多条dml实现原子提交？

MySQL事务必须显式开启，`BEGIN` 和 `START TRANSACTION` 效果相同

MySQL默认是自动提交模式（autocommit=1），每条DML语句执行完立刻生效，根本不会进入事务。想用事务包裹多条DML，第一步就是关掉自动提交——但不是靠改全局配置，而是用语句显式开启事务块。

推荐用 START TRANSACTION，语义更清晰；BEGIN 是别名，部分老文档写法，两者无区别。注意：BEGIN 不是存储过程里的 BEGIN...END 块，别混淆。

SET autocommit = 0 虽然也能进事务模式，但容易漏关、难追踪，不建议在应用逻辑中用
开启后，所有后续DML（INSERT/UPDATE/DELETE）都暂存在当前事务中，直到 COMMIT 或 ROLLBACK
事务开启后，如果连接断开或客户端异常退出，MySQL会自动 ROLLBACK，这点比某些ORM更可靠

`COMMIT` 成功不代表数据已刷盘，`innodb_flush_log_at_trx_commit` 才决定持久性

执行 COMMIT 后，MySQL返回“Query OK”，只表示事务已提交到InnoDB日志缓冲区，是否真正落盘取决于配置项 innodb_flush_log_at_trx_commit 的值：

1（默认）：每次 COMMIT 都触发 fsync 刷redo log到磁盘 → 强持久，性能略低
0：每秒刷一次日志，事务提交只写内存 → 可能丢一秒内事务
2：写入操作系统缓存即返回，由OS异步刷盘 → crash可能丢数据，但比0稍安全

线上业务强烈建议保持为 1。别只看 COMMIT 返回成功就认为万无一失。

事务中遇到错误不会自动回滚，必须由客户端主动判断并执行 `ROLLBACK`

MySQL本身不会因为某条DML报错（比如违反唯一约束、外键失败、字段超长）就中断整个事务或自动回滚。它只是让那条语句失败，事务状态仍为“活跃”，后续语句照常执行——这极易导致脏数据残留。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

正确做法是：在应用层捕获SQL错误码（如 1062 重复键、1452 外键约束失败），一旦出错立即发 ROLLBACK。例如：

START TRANSACTION;
INSERT INTO orders (id, user_id) VALUES (1001, 123);
INSERT INTO order_items (order_id, product_id) VALUES (1001, 999); -- 假设order_id=1001不存在，触发1452错误
-- 此时事务未结束！必须手动ROLLBACK，否则下一条语句还在这个事务里

很多ORM（如Python的SQLAlchemy、Java的Spring JDBC）支持声明式事务回滚，但底层仍是靠检测异常后发 ROLLBACK 指令。

长事务会阻塞MVCC清理，`SELECT` 也可能被锁，别以为只DML才进事务

事务不只是包裹 INSERT/UPDATE/DELETE。只要开了事务，哪怕只执行一条 SELECT，也会持有事务ID，影响InnoDB的purge线程清理undo log。更关键的是：

带 FOR UPDATE 或 LOCK IN SHARE MODE 的 SELECT 会加行锁，阻塞其他事务修改对应行
即使普通 SELECT，在 READ COMMITTED 或 REPEATABLE READ 隔离级别下，也会基于事务启动时刻的快照读取，拖慢全局版本链清理
一个运行30秒的事务，可能让undo log膨胀、history list堆积，最终拖慢整个实例

所以“事务包裹多条DML”这事，重点不在语法怎么写，而在于控制事务粒度：尽量短，别在事务里做HTTP调用、文件读写、循环sleep这类耗时操作。