事务是保障数据一致性的底线，用于消除“半成功”状态；跨表联动、先删后增、金额变更、带校验写入等场景必须使用；需InnoDB引擎并关闭autocommit；事务不能解决丢失更新、幻读及业务规则缺陷。
事务不是可选项，是数据不出错的底线
MySQL 里没有事务，就像银行柜台不核对账本就直接划款——看似快，但只要中间出一次错（网络断、程序崩、语句写错），数据库就可能卡在“张三扣了钱、李四没到账”的半截状态。这不是小概率事件，而是高并发或复杂业务下的必然风险。事务存在的唯一目的，就是把这种“半成功”状态彻底消灭。
哪些业务场景一不用事务就翻车
不是所有 SQL 都需要事务，但以下几类操作一旦漏掉 START TRANSACTION 和 COMMIT，轻则数据错乱，重则引发资损或审计事故：
-
跨表联动操作：比如下单时要同时写
orders表、扣减inventory库存、生成payment_log记录——少一个成功，整个订单就变成“已下单但没扣库存”或“已付款但没建单” -
先删后增/先查后改：像同步逻辑表到原子服务的典型流程：
DELETE FROM metric_impl WHERE logic_table_id = ?→ 查询现有数据 →INSERT INTO metric_impl ...；若删完还没插就中断，数据永久丢失 - 金额类原子变更：转账、充值返现、优惠券核销——必须保证“支出”和“收入”两条 UPDATE 同步生效，否则会计科目直接失衡
-
带校验逻辑的写入：例如“余额不能为负”，需先
SELECT balance，再判断是否允许扣款；若无事务隔离，两次查询之间被其他事务修改，就会绕过校验
为什么 InnoDB + 关闭 autocommit 才算真正启用事务
很多人写了 START TRANSACTION 却发现回滚无效，根本原因是踩了两个隐形坑：
-
MyISAM引擎根本不支持事务，哪怕语法写对也只会静默忽略 —— 必须确认表用的是InnoDB（SHOW CREATE TABLE account查引擎） - MySQL 默认
autocommit=1，每条 SQL 自动提交；此时START TRANSACTION只对后续语句有效，且一旦执行COMMIT或连接断开，事务自动结束 —— 生产环境务必显式执行SET autocommit = 0（会话级）或在连接池配置中统一关闭 - 忘记
ROLLBACK也很危险：异常捕获后只打印日志却不回滚，等于把错误状态“固化”进数据库
事务不是万能胶，它解决不了的问题更值得警惕
事务能保证“我这一组操作不残缺”，但无法解决外部干扰导致的逻辑冲突。比如：
- 两个事务同时读到 A 账户余额 1000 元，各自扣 800 元再写回 → 最终余额变成 200 元（应为 -600，但约束拦住了）→ 实际结果是 200，而不是预期的“失败”。这是典型的 丢失更新，靠事务本身无法拦截，得加
SELECT ... FOR UPDATE或应用层分布式锁 - 幻读在
REPEATABLE READ下仍可能发生（如 INSERT 导致 COUNT 结果变化），MySQL 用间隙锁缓解但不根治；真要杜绝，得升到SERIALIZABLE，代价是并发能力归零 - 事务无法防止业务规则漏洞：比如允许负余额的字段没加
CHECK约束，或外键未设 ON DELETE CASCADE，事务再稳也救不了设计缺陷
真正难的从来不是写 COMMIT，而是在哪一层做校验、什么时候加锁、哪些一致性该由数据库兜底、哪些必须靠业务代码死守——事务只是那根保险绳，别把它当成安全带、安全气囊和防撞梁的总和。
