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);模拟长事务，观察其他会话的可见性与阻塞情况
