MySQL事务需显式COMMIT或ROLLBACK，否则断连自动回滚；ROLLBACK仅撤销自最近START TRANSACTION后的变更；DDL会隐式提交；事务为会话级，跨连接不可见未提交数据。
START TRANSACTION 后必须显式 COMMIT 或 ROLLBACK
MySQL 默认是自动提交模式（autocommit=1），每条 SQL 语句单独成事务。一旦执行 START TRANSACTION 或 BEGIN，就进入手动事务模式——此时后续所有 DML（INSERT/UPDATE/DELETE）都不会立即生效，直到你明确输入 COMMIT 或 ROLLBACK。漏写这两者之一，连接断开时 MySQL 会自动回滚未提交的更改，但不会报错，容易误以为“数据已保存”。
常见错误现象：
START TRANSACTION;
INSERT INTO users(name) VALUES('alice');
-- 忘记 COMMIT 或 ROLLBACK，直接退出客户端
-- 再登录查，发现数据没进去
- 用
SELECT @@autocommit;确认当前会话是否处于手动事务模式（返回0表示已关闭自动提交） - 生产环境建议在事务开头加注释，如
-- TX: user registration，便于排查 - 避免在存储过程中混用
START TRANSACTION和SET autocommit = 0，后者会影响整个会话且不易追踪
ROLLBACK 只能撤销 START TRANSACTION 之后的变更
ROLLBACK 不是“撤回到数据库最初状态”，它只回退自最近一次 START TRANSACTION（或上一个 COMMIT/ROLLBACK）以来的所有更改。如果中间执行了 COMMIT，那之前的修改就永久生效，ROLLBACK 对其无效。
使用场景举例：批量导入时分段验证
START TRANSACTION;
INSERT INTO logs(msg) VALUES('step 1');
-- 检查某张表计数是否异常
SELECT COUNT(*) FROM temp_staging;
-- 发现异常，立刻回滚本批次
ROLLBACK;
-
ROLLBACK TO SAVEPOINT sp_name可实现部分回滚，但需提前用SAVEPOINT sp_name设立标记 - DDL 语句（如
CREATE TABLE、ALTER TABLE）在 MySQL 中会隐式触发COMMIT，导致之前 DML 一并提交——这是最容易踩的坑 - 若事务中调用了函数或触发器，且它们内部有 DML，也会被包含在本次事务中，一并回滚
COMMIT 后无法回退，且释放行锁与事务 ID
COMMIT 是不可逆操作。一旦成功返回，修改即持久化到磁盘（取决于 innodb_flush_log_at_trx_commit 配置），其他事务立刻可见，并释放该事务持有的所有行级锁和间隙锁。同时，InnoDB 会分配新的事务 ID（TRX_ID），旧事务上下文彻底清除。
性能影响注意点：
START TRANSACTION; UPDATE orders SET status='shipped' WHERE id IN (1001,1002,1003); -- 如果这里耗时过长，其他事务更新同一行会被阻塞 COMMIT; -- 此刻才真正释放锁
- 大事务（如处理几十万行）应拆分为小批次，每次
COMMIT释放锁和内存资源 - 高并发写入场景下，长时间不
COMMIT容易引发Lock wait timeout exceeded错误 -
innodb_lock_wait_timeout默认 50 秒，超时后客户端收到错误，但事务仍处于活跃状态，需手动ROLLBACK
事务边界在连接内有效，跨连接不共享
MySQL 的事务是会话级的。你在连接 A 中 START TRANSACTION 并修改数据，连接 B 立刻能通过 SELECT 看到这些未提交的数据吗？不能——除非连接 B 设置了 SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED。默认隔离级别（REPEATABLE READ）下，其他连接完全感知不到你的未提交变更。
典型误用：
-- 连接 A START TRANSACTION; UPDATE accounts SET balance = balance - 100 WHERE id = 1;-- 连接 B（新开终端） SELECT balance FROM accounts WHERE id = 1; -- 返回旧值，不是 -100 后的结果
- 应用层做事务控制时，必须确保所有相关 SQL 在同一个数据库连接中执行
- 连接池（如 HikariCP）可能复用连接，要注意连接归还前是否已
COMMIT或ROLLBACK，否则下次获取该连接的应用会继承残留事务状态 - 不要依赖“另一个连接来检查事务进度”，那是设计缺陷
事务真正的复杂点不在语法，而在于锁行为、隔离级别交互、以及连接生命周期管理。尤其当业务逻辑涉及多表更新+外部 API 调用时，COMMIT 放在哪一行，往往决定了数据一致性和系统可用性。
