MySQL 日志：undo log、redo log、binlog以及MVCC的介绍
一、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 的核心作用 —— 通过保留数据的多个版本，让读写操作能同时进行。