MySQL数据库基本概念解析：事务提交、回滚与并发控制机制

事务需显式COMMIT/ROLLBACK自动提交默认开启长事务危害大隔离级别、锁机制与索引共同决定并发行为。事务提交和回滚必须显式调用 COMMIT 或 ROLLBACKMySQL 默认开启自动提交autocommit1每条 SQL 语句单独成事务执行完立刻生效。一旦你用 BEGIN 或 START TRANSACTION 手动开启事务后续所有 DML 操作都不会写入磁盘直到你明确执行 COMMIT —— 否则连接断开、服务重启或客户端异常退出都会触发隐式 ROLLBACK。常见错误是以为“执行完 UPDATE 就算改好了”结果忘了 COMMIT导致数据看似成功却没持久化或者在异常处理里只捕获错误但没写 ROLLBACK留下脏数据。SET autocommit 0 会全局禁用自动提交但不推荐——容易遗忘恢复建议只在事务块内用 BEGIN 显式控制存储过程中不能直接用 COMMIT / ROLLBACK除非加 CONTAINS SQL 且未开启 autocommit否则报错 ERROR 1305 (42000): SAVEPOINT does not existDDL 语句如 ALTER TABLE在大多数引擎中会隐式触发 COMMIT导致前面未提交的 DML 一并提交——这是很多线上误操作的根源并发控制靠隔离级别 行锁不是靠“事务开始时间”MySQL 的可重复读REPEATABLE READ不是靠锁住整张表而是基于 MVCC多版本并发控制 当前读SELECT ... FOR UPDATE组合实现。同一事务中多次 SELECT 看到相同快照但若执行了 UPDATE 或加锁查询就会触发当前读可能看到其他事务已提交的新数据。很多人误以为设了 REPEATABLE READ 就能避免幻读其实不然普通 SELECT 不会看到新插入行但 INSERT ... SELECT 或 UPDATE ... WHERE 范围匹配时仍可能遇到间隙锁Gap Lock引发的幻读现象。查看当前会话隔离级别SELECT transaction_isolationInnoDB 中 READ COMMITTED 级别下每次 SELECT 都生成新快照适合高并发读多写少场景但无法避免不可重复读唯一能完全避免幻读的是 SERIALIZABLE但它会把所有普通 SELECT 转成 SELECT ... LOCK IN SHARE MODE性能代价极大极少在线上使用FOR UPDATE 和 LOCK IN SHARE MODE 锁行为差异极大SELECT ... FOR UPDATE 对扫描到的索引记录加排他锁X 锁其他事务无法对该记录做任何修改或加任何锁而 SELECT ... LOCK IN SHARE MODE 加的是共享锁S 锁允许其他事务加 S 锁但会阻塞 X 锁。两者都遵循“只锁命中索引”没走索引就是全表锁——这点极易被忽略。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手依托大模型帮助用户记录、整理和分析音视频内容体验用大模型做音视频笔记、整理会议记录。