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 就进了事务，其实还有几个关键点容易忽略：
- 自动提交模式（
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 是否真的改到了数据。比如账户余额不足却仍执行扣款，事务虽成功提交，但业务已出错。
