mysql并发编程中事务有什么作用_mysql事务控制说明

事务是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、唯一索引）、以及合理设计的隔离级别——别迷信默认值，也别一上来就锁全表。