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 的实际值。 
