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

来源：这里教程网时间：2026-02-28 20:41:12 作者：

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
，避免遗漏

事务不是银弹，它解决的是“逻辑单元一致性”，但无法绕过应用层竞态（比如先查余额再扣减，中间被其他事务修改）。真正健壮的并发控制，得结合乐观锁（