事务是MySQL并发数据一致的底线保障；必须用START TRANSACTION/COMMIT显式控制转账等逻辑单元；REPEATABLE READ下幻读取决于快照读或当前读；Go中需用tx.Exec而非db.Exec，且须检查Commit返回值。
MySQL 中事务不是“并发编程”的附加功能，而是并发场景下数据不出错的底线保障——没有事务，多线程/多请求同时改同一条记录，大概率会丢数据、算错账、状态错乱。
为什么并发时必须显式用 BEGIN 和 COMMIT
默认开启 AUTOCOMMIT=1，意味着每条 UPDATE、INSERT 都是独立事务。看似省事，实则埋雷：
- 转账类操作（扣A账户+加B账户）被拆成两个事务：若第一条成功、第二条失败，钱就凭空消失
- 库存扣减+订单生成，中间宕机 → 库存少了但订单没建，用户收不到货
- 多个请求同时读-改-写同一行（如点赞数
SET likes = likes + 1），最终结果可能只+1而非+2
正确做法是手动开启事务边界：
START TRANSACTION; UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE accounts SET balance = balance + 100 WHERE id = 2; COMMIT;
注意：START TRANSACTION 会自动关闭当前会话的自动提交，直到 COMMIT 或 ROLLBACK 后才恢复；不需要也不建议先执行 SET AUTOCOMMIT = 0。
REPEATABLE READ 隔离级别下仍可能遇到幻读？
MySQL 默认隔离级别是 REPEATABLE READ，它能防止脏读和不可重复读，但对“幻读”仅在**当前读（SELECT ... FOR UPDATE / SELECT ... LOCK IN SHARE MODE）下通过间隙锁（Gap Lock）拦截；普通 SELECT 仍可能看到新插入的行。
- 现象：事务 A 先查
SELECT * FROM orders WHERE status = 'pending'得到 5 条；事务 B 插入 1 条新 pending 订单并提交；事务 A 再查，还是 5 条（MVCC 快照）；但如果事务 A 执行SELECT ... FOR UPDATE，就会被阻塞或看到新行（取决于是否触发间隙锁） - 关键点：幻读是否发生，取决于你用的是快照读（普通
SELECT）还是当前读（带锁SELECT或 DML） - 若业务强依赖“绝对无新增”，应升级到
SERIALIZABLE，或用SELECT ... FOR UPDATE显式加锁
Golang 中用 db.Begin() 事务不生效的常见原因
Go 的 database/sql 包中，事务对象 *sql.Tx 是独立连接句柄，所有操作必须调用它的 Exec/Query 方法，否则会走默认连接池，脱离事务上下文：
- ❌ 错误：用
db.Exec()在tx开启后执行语句 → 不在事务内，自动提交 - ✅ 正确：所有操作都用
tx.Exec()、tx.Query() - ⚠️ 注意：事务未
Commit()且连接被 GC 回收时，MySQL 会自动回滚，但 Go 不报错——务必检查tx.Commit()返回值 - ? 建议：用
defer tx.Rollback()开头，再在成功时tx.Commit()前显式return，避免遗漏
事务不是银弹，它解决的是“逻辑单元一致性”，但无法绕过应用层竞态（比如先查余额再扣减，中间被其他事务修改）。真正健壮的并发控制，得结合乐观锁（WHERE version = ?）、数据库约束（CHECK、唯一索引）、以及合理设计的隔离级别——别迷信默认值，也别一上来就锁全表。
