MySQL事务隔离级别是如何实现的_深度解析锁表与MVCC结合-mysql教程-PHP中文网

可重复读能“反复读同一数据却不变”是因为事务中首次SELECT时创建read view，后续查询均基于该快照；MySQL通过间隙锁+MVCC组合避免幻读，但非纯MVCC实现；RC每次SELECT新建read view，RR只建一次。

mysql事务隔离级别是如何实现的_深度解析锁表与mvcc结合

可重复读为什么能“反复读同一数据却不变”

因为 InnoDB 在事务启动时生成了一个一致性读视图（read view），它不是拷贝数据，而是通过 DB_TRX_ID 和 undo log 动态“算出”你该看到哪个版本的数据。只要事务没提交，后续所有 SELECT 都基于这个快照，哪怕其他事务已更新并提交了那行。

关键点：read view 是在**第一条 SELECT 执行时才创建**，不是 BEGIN 时；如果你 BEGIN 后先 UPDATE 再 SELECT，read view 会延迟到 SELECT 时刻生成
容易踩的坑：autocommit=1 下，单条 SELECT 自成事务，每次查都新建 read view，根本谈不上“可重复读”
性能影响：高并发下活跃事务多，read view 数组变大，版本可见性判断开销略增，但远小于加锁等待

幻读真的被 MySQL 解决了吗

标准 SQL 定义中，可重复读（RR）不解决幻读；但 MySQL 的 RR 默认**用间隙锁（gap lock）+ MVCC 组合封住了 insert 场景**，所以你在普通 SELECT 中看不到新插入的行——但这不是纯靠 MVCC，是锁在起作用。

真实场景：事务 A 执行 SELECT * FROM t WHERE id > 5，InnoDB 不仅给查到的行加记录锁，还会对 (5, +∞) 加间隙锁；事务 B 此时 INSERT INTO t VALUES (6, 'x') 就会被阻塞
但如果你用 SELECT ... LOCK IN SHARE MODE 或 FOR UPDATE，间隙锁行为更明显；而纯 SELECT 下，间隙锁只在唯一索引/主键范围扫描时隐式启用
注意陷阱：RR 级别下，INSERT ... SELECT 或 UPDATE ... JOIN 这类语句仍可能触发幻读，因为它们走的是当前读（current read），绕过了 MVCC 快照

读已提交和可重复读的核心区别在哪一行代码里

就在 read view 的生成时机——READ COMMITTED 每次 SELECT 都新建 read view；REPEATABLE READ 整个事务只建一次。这导致前者能看到其他事务“刚提交”的变更，后者完全看不见。

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

实操验证：两个会话同时连进 MySQL，都设为 SET TRANSACTION ISOLATION LEVEL READ COMMITTED；会话 A UPDATE 并 COMMIT 后，会话 B 立即 SELECT 就能看见新值；换成 REPEATABLE READ，B 必须重新开启事务才能看到
参数差异：innodb_locks_unsafe_for_binlog=ON（已废弃）曾让 RR 退化为 RC 行为，现在不用管；但 binlog_format=STATEMENT 下，某些 RR 语义可能被复制打乱，建议用 ROW
兼容性提醒：PostgreSQL 的 RR 是真正快照隔离（SI），不会出现 MySQL 的间隙锁阻塞；迁移时要注意 insert 并发逻辑是否依赖这种“阻塞”

什么时候必须用锁，而不是靠 MVCC

MVCC 只管“读不阻塞”，但凡你要确保“读之后立刻写不冲突”，就得显式加锁——比如秒杀扣库存、银行转账余额校验，这类场景 MVCC 的快照无法防止写覆盖。

典型错误：用 SELECT balance FROM account WHERE id = 1 得到 100，再 UPDATE account SET balance = 90 WHERE id = 1 AND balance = 100，看似乐观锁，但如果并发高且没加 FOR UPDATE，两次 SELECT 可能都读到 100，第二个 UPDATE 仍会成功，造成超扣
正确做法：把 SELECT 改成 SELECT balance FROM account WHERE id = 1 FOR UPDATE，这样第二个人来查就会等，或者直接失败（取决于 innodb_lock_wait_timeout）
性能权衡：FOR UPDATE 是排他锁，会锁住索引记录+间隙，比纯 MVCC 查慢，但换来的是数据强一致；线上核心链路该锁还得锁，别迷信“无锁就快”

MVCC 和锁从来不是二选一，而是分工明确：MVCC 解决读-写冲突，锁解决写-写和读-写强一致需求。很多人卡在“为什么我开了 RR 还要加锁”，答案就在这里——快照只保你看得一致，不保你改得安全。