事务是“要么全成，要么全废”的操作包，本质为InnoDB引擎下需原子执行的一组DML；须关闭autocommit、显式START TRANSACTION、最终COMMIT或ROLLBACK；DDL会隐式提交并破坏事务。
事务就是“要么全成，要么全废”的操作包
MySQL 事务本质是一组逻辑相关的 INSERT、UPDATE 或 DELETE 操作，它们必须作为一个整体生效或失效。比如转账：A 减 100 元、B 加 100 元——这两步不能拆开；如果第二步失败，第一步也必须撤回，否则钱就“凭空消失”了。
关键前提是：InnoDB 引擎（MyISAM 不支持事务），且当前会话的 autocommit 必须为 0。MySQL 默认是 autocommit=1，也就是说每条 SQL 都自动提交，根本谈不上“打包控制”。不关掉它，START TRANSACTION 和 ROLLBACK 就形同虚设。
手动控制事务的三步铁律
不是写个 START TRANSACTION 就算进了事务——得闭环执行，漏一步就前功尽弃：
-
SET autocommit = 0（只对当前连接有效，建议每次连接后显式设置） -
START TRANSACTION（或BEGIN）——真正开启事务边界 - 执行完所有 DML 后，必须明确
COMMIT（成功）或ROLLBACK（出错时撤销）
常见错误：执行完 UPDATE 就断开连接，没 COMMIT，那修改当场丢失；或者误以为 SELECT 也能被回滚（它不能，只是读视图）。
隔离级别不是选“高就好”，而是看并发场景要防什么
MySQL 默认是 REPEATABLE READ，但它并不能完全避免幻读（比如 SELECT COUNT(*) 在事务中两次结果不同）。如果你的应用大量依赖“读一致性”，又频繁插入/删除，就得权衡：
-
READ COMMITTED：避免脏读，但不可重复读仍存在；适合日志类、统计类读多写少场景 -
REPEATABLE READ：InnoDB 用 MVCC + Next-Key Lock 实现，能防不可重复读和大部分幻读，但复杂查询可能锁更多行 -
SERIALIZABLE：强制串行执行，彻底防幻读，但性能暴跌，高并发下极易锁等待超时
别在业务代码里硬编码 SET TRANSACTION ISOLATION LEVEL，而应在连接池配置或应用层统一指定，避免混用导致行为不一致。
DDL 语句是事务里的“核按钮”，一碰就自动提交
哪怕你在 START TRANSACTION 之后执行 CREATE TABLE、ALTER TABLE 或 DROP INDEX，MySQL 会立刻隐式执行 COMMIT，前面所有未提交的 DML 都会被提前落库——而且无法回滚。
这很容易被忽略，尤其在运维脚本或迁移工具中混写 DDL 和 DML。安全做法是：
- 把 DDL 单独拎出来，在事务外执行
- 用
SHOW ENGINE INNODB STATUS查看最近事务是否被意外截断 - 开发阶段开启 general_log，确认实际执行顺序
事务不是万能保险丝，它只保 DML 的原子性；DDL、LOCK TABLES、SET 变量等都属于“事务破坏者”，得提前识别并隔离。
