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; <p>-- 连接 B（新开终端） SELECT balance FROM accounts WHERE id = 1; -- 返回旧值，不是 -100 后的结果应用层做事务控制时，必须确保所有相关 SQL 在同一个数据库连接中执行 连接池（如 HikariCP）可能复用连接，要注意连接归还前是否已
COMMIT或
ROLLBACK，否则下次获取该连接的应用会继承残留事务状态 不要依赖“另一个连接来检查事务进度”，那是设计缺陷
事务真正的复杂点不在语法，而在于锁行为、隔离级别交互、以及连接生命周期管理。尤其当业务逻辑涉及多表更新+外部 API 调用时，
COMMIT放在哪一行，往往决定了数据一致性和系统可用性。
