MySQL-概述

目录

一、MySQL的架构：

Server 层：

存储引擎层：

二、MySQL中更新流程涉及的日志：

Sever层日志 ——【binlog归档日志】：

引擎层日志 —— 【InnoDB引擎自有的redolog】：

binlog和redolog的区别：

三、引擎层——InnoDB提供的事务

事务的特性：

事务特性 之 隔离性：

事务隔离级别的实现——通过视图：

事务隔离级别 —— 可重复读：

可重复读隔离级别的实现——回滚日志：

避免长事务的原因（需要大量回滚日志  并 占用锁资源）：

---

一、MySQL的架构：

MySQL实战-01【5525】

MySQL 可以分为 Server 层和存储引擎层两部分。

Server 层：

包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。

1. 查询缓存：MySQL 拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。但是大多数情况下我会建议你不要使用查询缓存，查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。
2. 优化器：优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。【可能会存在优化器选错索引的情况，可以使force index强制使用某个索引。】
3. 执行器：首先判断用户是否有权限，有权限则打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。

存储引擎层：

负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。

索引是在存储引擎层实现的，所以并没有统一的索引标准，即不同存储引擎的索引的工作方式并不一样。而即使多个存储引擎支持同一种类型的索引，其底层的实现也可能不同。InnoDB的索引底层实现 —— B+Tree

---

二、MySQL中更新流程涉及的日志：

MySQL实战-02【5525】

Sever层日志 ——【binlog归档日志】：

• 用于主从复制，从库可以利用主库的bin log 进行重播，实现主从复制。
• 用于数据库基于某一个时间点的还原。

引擎层日志 —— 【InnoDB引擎自有的redolog】：

关键点就是先写日志，再写磁盘。InnoDB 引擎就会先把记录写到 redo log（粉板）里面，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做

binlog和redolog的区别：

1. 所属层级：redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
2. 记录内容：redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
3. 记录方式：redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

---

三、引擎层——InnoDB提供的事务

MySQL实战-03【5525】

事务的特性：

原子性、一致性、隔离性、持久性

事务特性 之 隔离性：

多个事务同时执行可能存在的问题：脏读，幻读，不可重复读，为了解决这些问题，就提出来事务隔离级别的概念。

• 读未提交，一个事务还没提交时，它做的变更就能被别的事务看到。造成脏读，幻读，不可重复读
• 读提交，一个事务提交之后，它做的变更才会被其他事务看到。可以避免 脏读。
• 可重复读，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
• 串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

事务隔离级别的实现——通过视图：

在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。

• 在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。
• 在“读提交”隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创建的。
• 在“读未提交”隔离级别下直接返回记录上的最新值，没有视图概念；
• 在“串行化”隔离级别下直接用加锁的方式来避免并行访问。

事务隔离级别 —— 可重复读：

使用场景：

假设你在管理一个个人银行账户表。一个表存了账户余额，一个表存了账单明细。到了月底你要做数据校对，也就是判断上个月的余额和当前余额的差额，是否与本月的账单明细一致。你一定希望在校对过程中，即使有用户发生了一笔新的交易，也不影响你的校对结果。

可重复读隔离级别的实现——回滚日志：

实际上每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值，通过回滚操作，都可以得到前一个状态的值。假设一个值从 1 被按顺序改成了 2、3、4，在回滚日志里面就会有类似下面的记录。

在查询这条记录的时候，不同时刻启动的事务会有不同的 read-view。如图中看到的，在视图 A、B、C 里面，这一个记录的值分别是 1、2、4，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制（MVCC）。对于 read-view A，要得到 1，就必须将当前值依次执行图中所有的回滚操作得到。即使现在有另外一个事务正在将 4 改成 5，这个事务跟 read-view A、B、C 对应的事务是不会冲突的。

当系统里没有比这个回滚日志更早的 read-view 的时候，说明当没有事务再需要用到这些回滚日志时，回滚日志会被删除。

避免长事务的原因（需要大量回滚日志  并 占用锁资源）：

长事务意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。除了对回滚段的影响，长事务还占用锁资源，也可能拖垮整个库。