MySQL 开启事务主要有显式启动（START TRANSACTION/BEGIN）和关闭自动提交（SET autocommit=0）两种方式，前者逻辑清晰、可控性强，后者需手动提交且易导致长事务；默认 autocommit=1，DDL 会隐式提交；推荐优先使用显式事务并注意异常回滚与事务粒度控制。
MySQL 开启事务主要有两种方式：显式启动和关闭自动提交。关键在于根据使用场景选择合适的方法，避免意外的数据不一致或长事务问题。
显式用 START TRANSACTION 或 BEGIN
这是最常用、最清晰的方式，适合一次性执行多条语句并明确控制提交或回滚的场景。
- 执行
START TRANSACTION;或BEGIN;后，后续所有 DML（INSERT/UPDATE/DELETE）操作都纳入当前事务 - 必须显式执行
COMMIT;才会真正写入数据；出错或主动放弃时用ROLLBACK; - 事务结束后自动结束，下一条语句不会自动进入新事务，需再次 START
- 支持设置保存点：
SAVEPOINT sp1;和ROLLBACK TO sp1;，便于局部回滚
关闭 autocommit 模式（SET autocommit = 0）
该方式让当前连接的所有 DML 默认处于事务中，直到你手动 COMMIT 或连接断开。
- 执行
SET autocommit = 0;后，每个 UPDATE/INSERT/DELETE 都不会立即生效，其他会话不可见（取决于隔离级别） - 必须手动
COMMIT;或ROLLBACK;，否则事务一直挂起，可能造成锁等待或长事务报警 - autocommit 是会话级变量，只影响当前连接，不影响其他客户端
- 适合需要连续执行多个事务性操作、且希望统一管理提交节奏的脚本或应用逻辑
注意隐式事务和自动提交行为
默认情况下 MySQL 的 autocommit = 1，意味着每条 DML 单独成事务，执行完立刻持久化。
- DDL 语句（如 CREATE、ALTER、DROP）会隐式触发 COMMIT，无法回滚其本身
- 某些语句（如 LOCK TABLES）也会导致当前事务自动提交
- 如果误设 autocommit = 0 又忘记 COMMIT，可能导致数据“看似没变”，实则卡在未提交状态
- 可通过
SELECT @@autocommit;查看当前值，用SELECT * FROM information_schema.INNODB_TRX;查活跃事务
推荐实践建议
日常开发和运维中，优先使用显式事务（START TRANSACTION），逻辑更可控、可读性更强。
- 避免长期依赖
SET autocommit = 0，尤其在交互式命令行中容易遗忘 COMMIT - 应用层应确保 try-catch + rollback 机制完整，防止异常导致事务悬挂
- 高并发场景下注意事务粒度，尽量缩短事务持续时间，减少锁冲突和死锁风险
- 测试阶段可用
SELECT SLEEP(5);模拟长事务，观察其他会话的可见性与阻塞情况
