一、MySQL 日志：undo log、redo log、binlog

undo log（回滚日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和 MVCC（隔离性）。
redo log（重做日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的持久性，主要用于掉电等故障恢复；
binlog （归档日志）：是 Server 层生成的日志，主要用于数据备份和主从复制；

MVCC（多版本并发控制）详解

MVCC是数据库领域用于解决高并发场景下读写冲突的核心技术。其核心思想是：为数据的每一次修改生成一个 “版本”，读操作只访问符合条件的历史版本，从而实现 “读不加锁、写不阻塞读”，大幅提升数据库并发性能。

二、MVCC 的核心目标：解决并发难题

在数据库并发场景中，传统的 “锁机制” 会导致 读写互斥（读操作加共享锁，写操作加排他锁，两者冲突），引发性能瓶颈。MVCC 的出现就是为了在 “并发控制” 与 “性能” 之间找到平衡，具体目标包括：

避免读写阻塞：读操作（SELECT）无需等待写操作释放锁，写操作（UPDATE/DELETE/INSERT）也无需阻塞读操作。
支持事务隔离级别：实现 MySQL 中的 Repeatable Read（可重复读） 和 Read Committed（读已提交） 隔离级别（InnoDB 默认使用 Repeatable Read，通过 MVCC 避免幻读）。
提高并发吞吐量：减少锁竞争，让多个事务可以同时读写数据库，提升系统整体处理能力。

通俗理解一下：可以把 MVCC 理解成数据库的 “时光机” 机制，专门解决多个人同时操作数据时的冲突问题。
打个比方：你在看一本电子书（读数据），同时另一个人在修改这本书的内容（写数据）。没有 MVCC 的话，你可能会看到乱七八糟的半成品内容，或者对方修改时你得一直等着不能看。
但有了 MVCC 就不一样了：
数据库会给每条数据拍 “快照”，你看书时翻到的是某一时刻的完整版本（快照读），不受别人修改的影响；
别人修改时，会新建一个新版本的数据，旧版本依然保留给正在读的人用；
等你看完（事务结束），旧版本可能会被悄悄清理掉，不占额外空间。
这样一来，“读” 和 “写” 互不干扰，不用排队等待，数据库并发处理能力就大大提高了。这就是 MVCC 的核心作用 —— 通过保留数据的多个版本，让读写操作能同时进行。