mysql如何使用显式事务控制语句_mysql begin/commit/rollback

mysql 显式事务什么时候必须用 BEGIN？

不是所有写操作都需要显式事务，只有当你需要确保多条语句“全成功或全失败”时才必须用。比如转账、库存扣减+订单创建、日志表和主表同步更新等场景。BEGIN（或等价的 START TRANSACTION）是开启事务的明确信号，不加它，MySQL 默认处于自动提交模式（autocommit=1），每条语句执行完立刻生效，ROLLBACK 无效。

• BEGIN 和 START TRANSACTION 完全等价，选一个习惯用就行；BEGIN WORK 也行，但不推荐，语义模糊
• 如果连接已处于事务中（比如上一个事务没 COMMIT 或 ROLLBACK），再执行 BEGIN 会隐式提交前一个事务——这是容易被忽略的“自动提交陷阱”
• 存储过程中不能用 BEGIN 开启事务（语法报错），得用 START TRANSACTION

为什么 COMMIT 后数据还是查不到？

常见于客户端连接未设置隔离级别或连接复用，导致你在一个连接里 COMMIT 了，但在另一个连接（或同一连接但未刷新查询缓存）里查不到最新数据。本质是事务隔离机制在起作用，不是语句没生效。

• 默认隔离级别 REPEAtable READ 下，事务内多次 select 看到的是事务开始时的快照，COMMIT 不影响当前事务内的读视图
• 跨连接查不到，大概率是另一连接没关闭事务（卡在 BEGIN 后没 COMMIT），阻塞了 MVCC 清理，或者用了 SELECT ... for UPDATE 持有锁
• COMMIT 是持久化动作，但不触发其他连接的缓存刷新——应用层如果做了查询结果缓存（如 ORM 的 identity map），要自己清掉

ROLLBACK 失效的三个典型原因

ROLLBACK 看似简单，但失效往往是因为事务根本没真正开启，或中途被意外中断。

• 执行了 DDL（如 ALTER TABLE、DROP INDEX）：MySQL 会隐式提交当前事务，之后 ROLLBACK 只能回滚 DDL 之后的操作
• 连接异常断开（超时、网络中断、客户端崩溃）：事务自动回滚，但如果你在重连后还试图 ROLLBACK，那只是对空事务操作，无效果
• 开启了 autocommit=1 却忘了关：即使写了 BEGIN，只要中间某条语句触发了隐式提交（比如上面的 DDL），后续就脱离事务上下文了

嵌套事务？MySQL 不支持，但可以模拟

MySQL 没有真正的嵌套事务（SAVEPOINT 不是嵌套，是事务内的回滚锚点）。想实现“大事务里部分回滚”，只能靠 SAVEPOINT。

• SAVEPOINT sp1 设立标记，ROLLBACK TO sp1 回滚到该点，但整个事务仍活跃，可继续 COMMIT 或 ROLLBACK
• SAVEPOINT 名字不区分大小写，重复定义会覆盖前一个，不会报错
• 注意：DDL 语句（如 CREATE TABLE）仍会清空所有 SAVEPOINT，且无法回滚 DDL 本身

事务的边界比看起来更脆弱——一条没留意的 SELECT ... FOR UPDATE、一次忘记关闭的连接、甚至 ORM 自动插入的 SET autocommit=0，都可能让 COMMIT 或 ROLLBACK 行为偏离预期。真正在意数据一致性的场景，建议把事务控制收束到最小、最明确的代码块，并始终检查 @@autocommit 和 @@transaction_isolation 的实际值。