mysql事务是innodb引擎支持的“全有或全无”操作包，通过undo log、redo log和mvcc实现原子性、持久性与并发控制，需显式用start transaction、commit/rollback定义边界，且默认autocommit=1。
MySQL事务就是“全有或全无”的操作包
MySQL事务不是某种特殊语法，而是对一组DML操作（INSERT、UPDATE、DELETE）的逻辑打包——它保证这些语句要么全部生效，要么全部作废。比如转账：A扣100、B加100，这两步必须绑定在一起；如果只执行了第一步就崩了，没事务就会导致钱凭空消失。
关键判断标准就一条：只有 InnoDB 引擎支持事务。MyISAM、MEMORY 等引擎哪怕写 START TRANSACTION 也无效，不会真正隔离或回滚。
默认 autocommit=1 是最常被忽略的坑
MySQL 默认每条 DML 都自动开启并提交一个事务，相当于“隐形事务”。这意味着你写完 UPDATE 就立刻落盘，根本没法用 ROLLBACK 撤销——除非先关掉自动提交：
-
SET autocommit = 0;（当前会话生效） - 再显式执行
START TRANSACTION;或BEGIN; - 最后用
COMMIT;或ROLLBACK;显式结束
注意：autocommit 是会话级变量，不同客户端连接互不影响；生产环境不建议全局关闭，只在需要手动控制的业务逻辑中临时设置。
事务不是“锁表”，而是靠 undo log 和 MVCC 实现的
很多人以为事务=加锁，其实底层机制更精细：
-
undo log记录修改前的数据快照，用于ROLLBACK回退 -
redo log记录页级物理修改，确保崩溃后能恢复已提交事务（保障持久性） - MVCC（多版本并发控制）让读操作不阻塞写，写操作也不阻塞读——这才是
REPEATABLE READ隔离级别下“可重复读”不靠锁实现的原因
所以事务开销主要来自日志写入和版本链维护，而不是简单粗暴地锁整张表。
事务边界必须由你自己定义，不是靠 SQL 数量
事务的起点不是第一条 DML，而是 START TRANSACTION（或 BEGIN）；终点也不是最后一条语句，而是 COMMIT 或 ROLLBACK。中间哪怕只有一条 UPDATE，只要没提交，其他会话就看不到变更。
常见误操作：
- 忘记
COMMIT，导致连接一直持有事务锁，拖慢整个库 - 在存储过程中嵌套事务，但没处理好保存点（
SAVEPOINT），导致部分回滚失败 - 用
SELECT触发事务（它本身不开启事务），误以为“查完就结束了”
真正决定事务范围的，永远是你写的那几条控制语句，不是数据变化了多少行。
