事务就是“要么全成，要么全废”的操作包
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变量等都属于“事务破坏者”，得提前识别并隔离。
