MySQL 的事务隔离级别是数据库并发控制的核心概念用于解决多个事务同时执行时可能产生的数据不一致问题。1. 默认值是MySQL InnoDB 默认的事务隔离级别是REPEATABLE READ可重复读。2. 四大隔离级别三个读异常脏话、不可重复、幻读解释脏读Dirty Read读到别的事务尚未提交的数据万一对方回滚这数据就是废的。不可重复读Non-Repeatable Read在同一事务内两次读取同一条记录因为别的事务修改并提交了导致两次结果不一致侧重于“改”。幻读Phantom Read在同一事务内两次执行同一个范围查询因为别的事务插入或删除了数据导致第二次多出或少了几行侧重于“增删”。隔离级别与异常的关系注意按照 SQL 标准REPEATABLE READ是允许幻读发生的。但 MySQL InnoDB 通过强大的 Next-Key Lock间隙锁行锁机制在这个级别下就杜绝了幻读。3.MySQL 默认选择 REPEATABLE READ绝大多数数据库如 Oracle、PostgreSQL、SQL Server默认都是READ COMMITTED MySQL 偏要与众不同。背后的原因不是“拍脑袋”而是由MySQL 主从复制基于 Binlog的历史架构和性能权衡共同决定的。我们可以把原因归结为三大支柱。一历史包袱与二进制日志Binlog的安全隐患最核心原因在 MySQL 5.0 及更早版本以及当下的某些配置中Binlog 的格式默认是STATEMENT基于语句的复制。也就是记录UPDATE t SET a1 WHERE id10;这样的 SQL 语句然后发给从库执行。如果此时隔离级别是READ COMMITTED会产生一个致命的主从数据不一致风险我们称之为“Binlog 惊魂”。让我们用一个经典场景复现假设主库并发执行以下两个事务TxA 删除TxB 插入时间线 1TxA 执行DELETE FROM users WHERE age 20;此时表中有 id1(age25) 和 id2(age30)TxA 扫到了这两行准备删除。时间线 2TxB 执行INSERT INTO users (id3, age28);并提交。时间线 3在READ COMMITTED下由于 TxB 已提交TxA 重新评估条件age20新插入的 id3 不会被删除因为 InnoDB 的删除是通过隐藏字段标记此时读视图变化了。时间线 4TxA 提交。主库结果id1, id2 被删id3 存活。Binlog 记录顺序STATEMENT 格式INSERTTxB的记录先写DELETETxA的记录后写。从库重放先执行INSERT插入 id3后执行DELETE FROM users WHERE age20;。在从库执行 DELETE 时它会无情地把刚刚插入的 id3 也一起删掉从库结果id1, id2, id3 全部被删。结果主从数据严重不一致如何解决MySQL 选择了REPEATABLE READ。在这个级别下TxA 在开始时创建了一致性读视图快照直到事务结束。即使 TxB 提交了TxA 依然看不到新插入的 id3所以 DELETE 语句只作用于它一开始看到的 id1 和 id2。这条 DELETE 记录到 Binlog 后在从库执行时也会基于从库的 MVCC 快照或锁机制只删除这两条从而保证主从一致。二MVCC 实现的读视图Read View生成时机不同为了理解这一点我们需要看一眼 InnoDB 的多版本并发控制MVCC机制。在READ COMMITTED下每一次执行普通SELECT语句都会重新生成一个新的 Read View读视图。在REPEATABLE READ下事务内第一次执行SELECT时生成一个 Read View并复用到事务结束。这种机制天然保证了“可重复读”并且为基于 STATEMENT 的复制提供了确定性。虽然生成 Read View 的代价很小但REPEATABLE READ减少了生成的次数在极高并发下对 CPU 也算一种微小的优化。三间隙锁Gap Lock带来的“伪串行化”优势虽然REPEATABLE READ带来了更高的数据一致性保障但它也有代价——间隙锁。为了阻止幻读InnoDB 不仅锁住命中的行Record Lock还会锁住索引记录之间的“间隙”Gap Lock。TxA (REPEATABLE READ)开启事务执行范围查询WHERE id BETWEEN10 AND 20获得间隙锁锁定 (10,20)之间的所有间隙再次查询结果集不变幻读被阻止提交事务释放间隙锁TxB (试图插入)尝试插入 id15阻塞等待因间隙锁未释放等待中...TxA提交后插入成功但此时已不影响TxA的一致性事务并发与幻读防范间隙锁作用MySQL 选择REPEATABLE READ核心是为了兼容早期的 STATEMENT 格式 Binlog 以保证主从一致性。虽然现在有了更安全的ROW基于行格式 Binlog推荐使用但这个默认级别作为历史传承和“更安全”的默认配置被保留了下来。4. 现代视角下的权衡既然 ROW 格式 Binlog 解决了主从不一致问题为什么 MySQL 8.0 依然不改默认值兼容性与平滑升级对于无数遗留系统修改默认隔离级别可能引发未知的性能回退或死锁变化作为基础软件MySQL 必须保持高度的向下兼容。业务语义更严谨对于金融、报表统计等需要事务内多次读取同一批数据的场景REPEATABLE READ直接提供了开箱即用的强一致性减少了应用层处理“不可重复读”的代码负担。但也要注意它的“副作用”由于间隙锁的存在在高并发写入尤其是高冲突的插入场景下REPEATABLE READ比READ COMMITTED更容易产生死锁。因为间隙锁是“范围锁”两个事务很容易相互等待。5. MySQL 的隔离级别决策逻辑READ UNCOMMITTEDREAD COMMITTEDREPEATABLE READSERIALIZABLE用户发起事务当前隔离级别无锁读性能极致但如同走钢丝易脏读极少生产环境使用Oracle/PostgreSQL默认每次查询生成新快照无间隙锁并发高但主从需配合ROW格式BinlogMySQL默认首次查询生成快照并复用加间隙锁防幻读主从兼容性好STATEMENT/ROW均可代价更高死锁风险所有读加共享锁完全串行化性能最差仅用于极端严格场景结束事务结论“MySQL 默认是 REPEATABLE READ。这主要源于早期的 STATEMENT 模式 Binlog 复制如果使用 READ COMMITTED 会导致主从数据不一致。虽然现在我们可以通过设置 binlog_formatROW 并切换到 READ COMMITTED 来获得更高并发和更少死锁但 InnoDB 为了向后兼容和提供更稳健的默认行为在 8.0 版本中依然保留了 REPEATABLE READ 作为默认值。”
MySQL 的事务隔离级别是数据库并发控制的核心概念用于解决多个事务同时执行时可能产生的数据不一致问题。1. 默认值是MySQL InnoDB 默认的事务隔离级别是REPEATABLE READ可重复读。2. 四大隔离级别三个读异常脏话、不可重复、幻读解释脏读Dirty Read读到别的事务尚未提交的数据万一对方回滚这数据就是废的。不可重复读Non-Repeatable Read在同一事务内两次读取同一条记录因为别的事务修改并提交了导致两次结果不一致侧重于“改”。幻读Phantom Read在同一事务内两次执行同一个范围查询因为别的事务插入或删除了数据导致第二次多出或少了几行侧重于“增删”。隔离级别与异常的关系注意按照 SQL 标准REPEATABLE READ是允许幻读发生的。但 MySQL InnoDB 通过强大的 Next-Key Lock间隙锁行锁机制在这个级别下就杜绝了幻读。3.MySQL 默认选择 REPEATABLE READ绝大多数数据库如 Oracle、PostgreSQL、SQL Server默认都是READ COMMITTED MySQL 偏要与众不同。背后的原因不是“拍脑袋”而是由MySQL 主从复制基于 Binlog的历史架构和性能权衡共同决定的。我们可以把原因归结为三大支柱。一历史包袱与二进制日志Binlog的安全隐患最核心原因在 MySQL 5.0 及更早版本以及当下的某些配置中Binlog 的格式默认是STATEMENT基于语句的复制。也就是记录UPDATE t SET a1 WHERE id10;这样的 SQL 语句然后发给从库执行。如果此时隔离级别是READ COMMITTED会产生一个致命的主从数据不一致风险我们称之为“Binlog 惊魂”。让我们用一个经典场景复现假设主库并发执行以下两个事务TxA 删除TxB 插入时间线 1TxA 执行DELETE FROM users WHERE age 20;此时表中有 id1(age25) 和 id2(age30)TxA 扫到了这两行准备删除。时间线 2TxB 执行INSERT INTO users (id3, age28);并提交。时间线 3在READ COMMITTED下由于 TxB 已提交TxA 重新评估条件age20新插入的 id3 不会被删除因为 InnoDB 的删除是通过隐藏字段标记此时读视图变化了。时间线 4TxA 提交。主库结果id1, id2 被删id3 存活。Binlog 记录顺序STATEMENT 格式INSERTTxB的记录先写DELETETxA的记录后写。从库重放先执行INSERT插入 id3后执行DELETE FROM users WHERE age20;。在从库执行 DELETE 时它会无情地把刚刚插入的 id3 也一起删掉从库结果id1, id2, id3 全部被删。结果主从数据严重不一致如何解决MySQL 选择了REPEATABLE READ。在这个级别下TxA 在开始时创建了一致性读视图快照直到事务结束。即使 TxB 提交了TxA 依然看不到新插入的 id3所以 DELETE 语句只作用于它一开始看到的 id1 和 id2。这条 DELETE 记录到 Binlog 后在从库执行时也会基于从库的 MVCC 快照或锁机制只删除这两条从而保证主从一致。二MVCC 实现的读视图Read View生成时机不同为了理解这一点我们需要看一眼 InnoDB 的多版本并发控制MVCC机制。在READ COMMITTED下每一次执行普通SELECT语句都会重新生成一个新的 Read View读视图。在REPEATABLE READ下事务内第一次执行SELECT时生成一个 Read View并复用到事务结束。这种机制天然保证了“可重复读”并且为基于 STATEMENT 的复制提供了确定性。虽然生成 Read View 的代价很小但REPEATABLE READ减少了生成的次数在极高并发下对 CPU 也算一种微小的优化。三间隙锁Gap Lock带来的“伪串行化”优势虽然REPEATABLE READ带来了更高的数据一致性保障但它也有代价——间隙锁。为了阻止幻读InnoDB 不仅锁住命中的行Record Lock还会锁住索引记录之间的“间隙”Gap Lock。TxA (REPEATABLE READ)开启事务执行范围查询WHERE id BETWEEN10 AND 20获得间隙锁锁定 (10,20)之间的所有间隙再次查询结果集不变幻读被阻止提交事务释放间隙锁TxB (试图插入)尝试插入 id15阻塞等待因间隙锁未释放等待中...TxA提交后插入成功但此时已不影响TxA的一致性事务并发与幻读防范间隙锁作用MySQL 选择REPEATABLE READ核心是为了兼容早期的 STATEMENT 格式 Binlog 以保证主从一致性。虽然现在有了更安全的ROW基于行格式 Binlog推荐使用但这个默认级别作为历史传承和“更安全”的默认配置被保留了下来。4. 现代视角下的权衡既然 ROW 格式 Binlog 解决了主从不一致问题为什么 MySQL 8.0 依然不改默认值兼容性与平滑升级对于无数遗留系统修改默认隔离级别可能引发未知的性能回退或死锁变化作为基础软件MySQL 必须保持高度的向下兼容。业务语义更严谨对于金融、报表统计等需要事务内多次读取同一批数据的场景REPEATABLE READ直接提供了开箱即用的强一致性减少了应用层处理“不可重复读”的代码负担。但也要注意它的“副作用”由于间隙锁的存在在高并发写入尤其是高冲突的插入场景下REPEATABLE READ比READ COMMITTED更容易产生死锁。因为间隙锁是“范围锁”两个事务很容易相互等待。5. MySQL 的隔离级别决策逻辑READ UNCOMMITTEDREAD COMMITTEDREPEATABLE READSERIALIZABLE用户发起事务当前隔离级别无锁读性能极致但如同走钢丝易脏读极少生产环境使用Oracle/PostgreSQL默认每次查询生成新快照无间隙锁并发高但主从需配合ROW格式BinlogMySQL默认首次查询生成快照并复用加间隙锁防幻读主从兼容性好STATEMENT/ROW均可代价更高死锁风险所有读加共享锁完全串行化性能最差仅用于极端严格场景结束事务结论“MySQL 默认是 REPEATABLE READ。这主要源于早期的 STATEMENT 模式 Binlog 复制如果使用 READ COMMITTED 会导致主从数据不一致。虽然现在我们可以通过设置 binlog_formatROW 并切换到 READ COMMITTED 来获得更高并发和更少死锁但 InnoDB 为了向后兼容和提供更稳健的默认行为在 8.0 版本中依然保留了 REPEATABLE READ 作为默认值。”
与广度优先搜索(BFS)在连通块计数中的核心原理与实现)
