事务中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）和索引使用情况，而不是隔离级别本身。
