MySQL事务是原子性执行的SQL操作单元,以BEGIN/START TRANSACTION开始、COMMIT/ROLLBACK结束,仅InnoDB等支持事务的引擎有效;具备ACID特性:原子性确保全成功或全回滚,一致性依赖约束与应用逻辑,隔离性由transaction_isolation级别控制,持久性受innodb_flush_log_at_trx_commit影响。

什么是 MySQL 事务
MySQL 事务是一组原子性执行的 SQL 操作,要么全部成功提交,要么全部回滚。它不是某个单独语句,而是一个逻辑工作单元,通常以 BEGIN 或 START TRANSACTION 开始,以 COMMIT 或 ROLLBACK 结束。
只有使用支持事务的存储引擎(如 InnoDB)的表才真正具备事务能力。MyISAM 表不支持事务,即使写了 START TRANSACTION 也不会生效。
ACID 四个特性的实际表现
ACID 不是抽象概念,而是 MySQL 在底层通过日志、锁、MVCC 等机制强制保障的行为契约:
-
Atomicity(原子性):事务中任意一条语句失败,
ROLLBACK后所有已执行变更都会被撤销。注意:不是所有错误都会自动触发回滚,比如语法错误会立即报错并中断事务,但约束冲突(如唯一键重复)需显式判断后ROLLBACK。 -
Consistency(一致性):由应用逻辑 + 数据库约束共同维护。MySQL 不负责业务规则,只保证外键、CHECK、NOT NULL 等约束不被破坏。例如插入非法日期可能不报错(取决于
sql_mode),但违反UNIQUE一定会中断一致性。 -
Isolation(隔离性):由
transaction_isolation级别控制,默认是REPEATABLE-READ。不同级别直接影响是否能看到其他事务未提交的数据、是否发生幻读等。高隔离级别会增加锁竞争,降低并发性能。 -
Durability(持久性):依赖
innodb_flush_log_at_trx_commit配置。设为1(默认)时,每次COMMIT都会刷盘 redo log,崩溃后可恢复;设为0或2有丢事务风险,但写入更快。
事务开启与提交的常见误区
很多人以为只要写了 START TRANSACTION 就进了事务,其实还有几个关键点容易忽略:
本书全面介绍PHP脚本语言和MySOL数据库这两种目前最流行的开源软件,主要包括PHP和MySQL基本概念、PHP扩展与应用库、日期和时间功能、PHP数据对象扩展、PHP的mysqli扩展、MySQL 5的存储例程、解发器和视图等。本书帮助读者学习PHP编程语言和MySQL数据库服务器的最佳实践,了解如何创建数据库驱动的动态Web应用程序。
- 自动提交模式(
autocommit=1)下,单条 DML 语句执行完立刻提交,必须先执行SET autocommit = 0或用START TRANSACTION才能进入多语句事务。 -
COMMIT和ROLLBACK不仅结束当前事务,还会隐式开启下一个事务(在autocommit=0模式下)。所以连续执行多个事务时,不需要重复写START TRANSACTION。 - DDL 语句(如
CREATE TABLE、ALTER TABLE)在 MySQL 中会**自动提交**当前事务,无法回滚。这是硬限制,不是 bug。 - 长事务(运行时间过长)会阻碍 purge 线程清理 undo log,导致
ibdata1文件膨胀、历史版本堆积,甚至引发Lock wait timeout exceeded错误。
一个典型事务操作示例
下面这段代码演示了转账场景中最基本的事务结构和错误处理思路:
START TRANSACTION; UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE accounts SET balance = balance + 100 WHERE id = 2; -- 检查是否更新成功(例如用 ROW_COUNT() 判断影响行数) IF ROW_COUNT() = 0 THEN ROLLBACK; ELSE COMMIT; END IF;
注意:纯 SQL 脚本中不能直接写 IF 这类流程控制,上面只是示意逻辑。实际应用中,这类判断应放在应用层(Python/Java/PHP)或存储过程中。MySQL 客户端执行时,需要确保连接处于 autocommit=0 状态,并手动捕获错误后决定是否 ROLLBACK。
最常被跳过的一步是——没检查 UPDATE 是否真的改到了数据。比如账户余额不足却仍执行扣款,事务虽成功提交,但业务已出错。









