MySQL日志

MySQL日志

1.MySQL六种日志：

1. 重做日志（redo log）
2. 回滚日志（undo log）
3. 归档日志（binlog）
4. 错误日志（errorlog）
5. 慢查询日志（slow query log）
6. 一般查询日志（general log）
7. 中继日志（relay log）

对MySQL来说，逻辑备份日志（binlog）、重做日志（redolog）、回滚日志（undolog）、锁技术 + MVCC

• 原子性：通过undolog来实现
• 持久性：通过binlog、redolog来实现
• 隔离性：通过(读写锁+MVCC)来实现
• 一致性：MySQL通过原子性，持久性，隔离性最终实现（或者说定义）数据一致性

1.1. redo log

MySQL 里有个问题，如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程 IO 成本、查找成本都很高

为了解决这个问题，MySQL使用了WAL技术

WAL的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘

1.2. 疑问（摘抄自与ChatGPT）

​ 但是写日志，不也是写磁盘操作吗？

ChatGPT

确实，写日志也是一种写磁盘的操作。不过，WAL 的设计使得写日志比直接写数据有一些优势：

1. 顺序写入 vs 随机写入：

• 日志通常是追加的顺序写入，这比随机写入要快得多。直接将变更写入数据库可能会涉及随机写入，尤其是在数据分布在磁盘不同位置时

2. 缓冲和批量处理：

• 日志可以先写入内存缓冲区，然后批量写入磁盘，这样可以减少磁盘的写入次数，提高效率。数据库数据的写入可能需要多次随机写操作

3. 崩溃恢复：

• 写日志可以确保在系统崩溃时有一个完整的变更记录，重启后可以根据日志恢复数据。直接写数据则可能在崩溃时留下不一致的状态

4. 原子操作：

• 写日志操作通常是原子的，要么完全成功要么完全失败，这样可以保证数据的一致性。直接写数据可能在操作中途出现问题导致数据不一致。

因此，虽然写日志也是写磁盘的操作，但由于其顺序写入和缓冲等特点，使得它在性能和数据一致性方面有显著的优势

具体来说，当有一条update语句要执行的时候，InnoDB 引擎就会先把记录写到 redo log里面，并更新内存，这个时候更新就算完成了

同时，InnoDB引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做

有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe

crash-safe：
  可以对照前面赊账记录的例子。只要赊账记录记在了小黑板上或写在了账本上，即使秀才突然被老邢抓走几天，回来后依然可以通过账本和小黑板上的数据明确赊账账目。就是维护数据的持久性
  本质上说，crash-safe 就是落盘处理，将数据存储到了磁盘上，断电重启也不会丢失

1.3. bin log

上面我们聊到的“小黑板” redo log 是 InnoDB 引擎特有的日志，而 Server 层也有自己的日志，称为binlog（归档日志），其实就是用来恢复数据用的

面试官：那MySQL为啥要有redo log 和 binlog两个日志呢？只留一个不香么？

熊猫：因为最开始 MySQL 里并没有 InnoDB 引擎。MySQL 自带的引擎是 MyISAM，但是 MyISAM 没有 crash-safe 的能力，而 binlog 日志只用于归档

InnoDB 是另一个公司以插件形式引入 MySQL 的。我们知道，只依靠 binlog 是没有 crash-safe 能力的，所以 InnoDB 使用另外一套日志系统——也就是 redo log 来实现 crash-safe 能力

面试官：那这两个日志主要有哪些区别？

redo log 是 InnoDB 引擎特有的；
binlog 是 MySQL 的 Server 层实现的，所有引擎共用

redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；
binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=1 这一行的 c 字段加 1 ”

redo log 是循环写的，空间固定会用完然后复写；
binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志

不全...文章来自于https://blog.csdn.net/qq_39390545/article/details/115214802

2. ACID

2.1. 原子性原理

事务通常是以BEGIN TRANSACTION 开始，以 COMMIT 或 ROLLBACK 结束

COMMIT 表示提交，即提交事务的所有操作并持久化到数据库中
ROLLBACK 表示回滚，即在事务中运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库所有已完成的操作全部撤销，回滚到事务开始时的状态，这里的操作指对数据库的更新操作，已执行的查询操作不用管。这时候也就需要用到 undolog 来进行回滚

undolog：

每条数据变更（INSERT/UPDATE/DELETE/REPLACE）等操作都会生成一条undolog记录，在SQL执行前先于数据持久化到磁盘
当事务需要回滚时，MySQL会根据回滚日志对事务中已执行的SQL做逆向操作，比如 DELETE 掉一行数据的逆向操作就是再把这行数据 INSERT回去，其他操作同理

2.2. 持久性原理

先了解一下MySQL的数据存储机制，MySQL的表数据是存放在磁盘上的，因此想要存取的时候都要经历磁盘 IO,然而即使是使用 SSD 磁盘 IO 也是非常消耗性能的。为此，为了提升性能 InnoDB 提供了缓冲池(Buffer Pool)，Buffer Pool 中包含了磁盘数据页的映射，可以当做缓存来使用：

读数据：会首先从缓冲池中读取，如果缓冲池中没有，则从磁盘读取在放入缓冲池；
写数据：会首先写入缓冲池，缓冲池中的数据会定期同步到磁盘中；
  我们知道，MySQL表数据是持久化到磁盘中的，但如果所有操作都去操作磁盘，等并发上来了，那处理速度谁都吃不消，因此引入了缓冲池(Buffer Pool)的概念，Buffer Pool 中包含了磁盘中部分数据页的映射，可以当做缓存来用；这样当修改表数据时，我们把操作记录先写到Buffer Pool中，并标记事务已完成，等MySQL空闲时，再把更新操作持久化到磁盘里（你可能会问，到底什么时候执行持久化呢？1、MySQL线程低于高水位；2、当有其他查询、更新语句操作该数据页时），从而大大缓解了MySQL并发压力

但是它也带来了新的问题，当MySQL系统宕机，断电时Buffer Pool数据不就丢了？

因为我们的数据已经提交了，但此时是在缓冲池里头，还没来得及在磁盘持久化，所以我们急需一种机制需要存一下已提交事务的数据，为恢复数据使用

于是 redolog + binlog的经典组合就登场了，可参考 https://blog.csdn.net/qq_39390545/article/details/115214802

2.3. 隔离性原理

隔离性是事务ACID特性里最复杂的一个。在SQL标准里定义了四种隔离级别，每一种级别都规定一个事务中的修改，哪些是事务之间可见的，哪些是不可见的

级别越低的隔离级别可以执行越高的并发，但同时实现复杂度以及开销也越大

搞懂MySQL事务隔离级别请参考 https://blog.csdn.net/qq_39390545/article/details/107343711

Mysql 隔离级别有以下四种（级别由低到高）：

搞懂了隔离级别以及实现原理其实就可以理解ACID里的隔离性了。前面说过原子性，隔离性，持久性的目的都是为了要做到一致性，但隔离型跟其他两个有所区别，原子性和持久性是为了要实现数据的正确、可用，比如要做到宕机后的恢复、事务的回滚等，保证数据是正确可用的

那么隔离性是要做到什么呢？

隔离性要管理的是：多个并发读写请求（事务）过来时的执行顺序。像交警在马路口儿指挥交通一样，当并发处理多个DML更新操作时，如何让事务操作他该看到的数据，出现多个事务处理同一条数据时，让事务该排队的排队，别插队捣乱，保证数据和事务的相对隔离，这就是隔离性要干的事儿

一段大白话，听的明明白白的同学们，记得收藏转发一波，或许，你能帮到别人！

所以，从隔离性的实现原理上，我们可以看出这是一场数据的可靠性与性能之间的权衡。

2.4. 一致性原理

一致性，我们要保障的是数据一致性，数据库中的增删改操作，使数据库不断从一个一致性的状态转移到另一个一致性的状态

事务该回滚的回滚，该提交的提交，提交后该持久化磁盘的持久化磁盘，该写缓冲池的写缓冲池+写日志；对于数据可见性，通过四种隔离级别进行控制，使得库表中的有效数据范围可控，保证业务数据的正确性的前提下，进而提高并发程度，支撑服务高QPS的稳定运行，保证数据的一致性，这就是咱们叨叨叨说的清楚想不明白的数据库ACID四大特性