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触发事务（它本身不开启事务），误以为“查完就结束了”
真正决定事务范围的，永远是你写的那几条控制语句，不是数据变化了多少行。
