mysql如何处理事务中的SQL语句_mysql事务执行顺序

事务中sql语句按书写顺序逐条执行，但对外可见性由COMMIT决定；错误不会自动回滚，需显式ROLLBACK或异常处理器兜底。

事务中sql语句的执行顺序由提交时机决定，不是按书写顺序自动生效

mysql 事务里写多条 INSERT、UPDATE 或 delete，它们在逻辑上是“原子性”地一起生效或一起回滚——但实际执行时，每条语句仍会逐条解析、校验、加锁、修改数据页。关键在于：**这些变更对其他事务不可见，直到你执行 COMMIT；而一旦执行 ROLLBACK，所有已执行语句的效果都会被撤销**。

常见误解是“先写的先生效”，其实不然。例如：

START TRANSACTION; UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE accounts SET balance = balance + 100 WHERE id = 2; -- 此时两个 UPDATE 都已完成（本地可见），但其他事务查不到变化 COMMIT;

如果中间某条语句报错（比如违反唯一约束），MySQL 不会自动回滚前面已成功的语句——除非你启用了 SET autocommit = 0 并显式捕获错误后调用 ROLLBACK。

autocommit 关闭后，事务边界必须手动控制

默认情况下 MySQL 的 autocommit = 1，意味着每条 DML 语句都自动构成一个独立事务。想让多条语句受同一事务控制，必须先关掉它：

• SET autocommit = 0; —— 后续所有 DML 都会累积到当前事务，直到遇到 COMMIT 或 ROLLBACK
• START TRANSACTION; 或 BEGIN; —— 显式开启新事务（也会隐式设置 autocommit = 0）
• 执行完 COMMIT 后，autocommit 状态不变，但新事务需重新 START TRANSACTION

容易踩的坑：select 不触发事务提交，但某些带锁的 SELECT ... for UPDATE 会参与事务锁管理；DDL 语句（如 ALTER table）在大多数存储引擎中会隐式提交当前事务。

事务内语句失败不会自动回滚，得靠你自己兜底

MySQL 默认不提供“语句级自动回滚”。比如：

START TRANSACTION; INSERT INTO logs VALUES ('start'); INSERT INTO logs VALUES ('error'); -- 假设这里因主键冲突失败 INSERT INTO logs VALUES ('end'); -- 第一条 INSERT 依然留在事务中，第三条不执行，但你得自己 ROLLBACK

这意味着：

• 应用层必须检查每条语句的返回状态（比如 mysqli 的 mysqli_error() 或 pdo 的 errorCode()）
• 一旦检测到错误，应立即执行 ROLLBACK，否则连接可能长期持有锁、占用 undo log
• 存储过程里可用 DECLARE EXIT HANDLER FOR SQLEXCEPTION 自动捕获并回滚

注意：部分客户端（如某些 ORM）会在执行失败时自动发送 ROLLBACK，但这属于封装行为，不是 MySQL 服务端特性。

隔离级别影响的是“看到什么”，不是“执行顺序”

很多人混淆“执行顺序”和“可见性顺序”。事务的 READ COMMITTED 或 REPEATABLE READ 只决定当前事务能读到哪些版本的数据，不影响语句本身的执行流程。例如：

• 在 REPEATABLE READ 下，事务 A 先 SELECT 一次，之后即使事务 B 修改并提交了同一行，A 再 SELECT 还是看到旧值
• 但事务 A 自己执行的 UPDATE 仍会基于最新快照做更新判断（即“当前读”），不会受自己之前 SELECT 结果影响
• INSERT ... SELECT 这类语句，在事务中会按实际执行时刻读取源表快照，与隔离级别强相关

真正影响执行行为的，是锁类型（record lock / gap lock / next-key lock）和索引使用情况，而不是隔离级别本身。