Mysql不讲武德— —来骗、偷袭我这个27岁老同志

1、架构模块

架构分为服务层和存储引擎层，服务层负责SQL执行操作，存储引擎层负责存储管理数据。

这就是服务层

一条SQL进入Mysql的步骤：

• 连接器（半双工）
• 缓存（默认关闭不使用）
• 解析器（语法解析+预处理）
• 优化器（执行计划，索引选择）
• 执行器（操作存储引擎，返回结果）

---

存储引擎层是可以替换的，支持多种存储引擎

InnoDB：对数据一致性要求高，需要事务

MyISAM：对查性能要求高，但是写很少几乎无

Memory：需要一个临时表用于查询，放在内存中的

或者可以根据规范用C自己写一个存储引擎（服务层和存储引擎层的交互协议是固定的）

2、InnoDB存储引擎

InnoDB引擎下，有几个关键设计：

• Buffer Pool（缓冲池）
• 刷脏（缓冲池数据同步到磁盘）
• Crash-safe（保证崩溃后的数据安全）
• WAL（write ahead log，日志先行机制）
• 二段式提交（保证日志和磁盘一致性）

---

DB存在的大难题：磁盘随机读写慢（机械硬盘更明显）

↓

【缓存池--->解决：磁盘随机读写慢】

随机读写磁盘是耗时的，先加载到缓存池操作数据，这样速度快很多。

↓

【刷脏--->解决：缓冲池和磁盘不一致】

缓冲池的数据是脏数据，需要定时刷脏到磁盘。

↓

【WAL机制--->解决：保证崩溃后的数据安全】

刷脏非实时，DB崩溃后缓冲池会丢数，要保证Crash-safe；

在写入缓冲池的同时写入redolog，定时把redolog的数据刷到磁盘，这就是WAL机制；

↓

【二段式提交--->解决：redolog和binlog 不一致（主从不一致）】

redolog的数据设置2种状态：pre和commit

日志执行顺序：redolog pre ---> binlog ---> redolog commit

3、索引设计

索引类型主要是三种：

• 普通索引，normal
• 唯一索引，unique
• 全文索引，fulltext

（主键默认唯一索引和普通索引，两种比较常用）

索引实现方法就2种：hash索引 、 B+树索引

1、hash索引是最快的的O(1)，查单个够快，但是不支持范围查询的，业务中没法使用….

2、B+树索引，mysql优化的专属产物，速度是比hash慢，但是支持范围查询，综合性能强啊！

---

索引如何发展成B+树？

二叉查找树，bst，缺点：极端情况下变成链表，O(N)

↓

平衡二叉查找树，avl，缺点：深度太多，导致磁盘IO频繁

↓

多路平衡查找树，b tree，缺点：拉取批量数据时性能低下，因为要跨不同父节点取数，IO次数不稳定

↓

加强版-多路平衡查找树，b+tree，优点：

• 叶节点存储数据并增加左右叶节点的指针，叶节点形成链表。扫描数据就不需要跨不同父节点取数，IO次数降低。
• 根节点不存储数据而是存储更多的key，大大降低树的高度。

B+树的特点

一个深度为3的B+Tree索引可以维护10^3 * 10^3 * 10^3 = 10亿 条记录

计算方式

InnoDB存储引擎中页的大小为16KB，一般表的主键类型为INT（占用4个字节）或BIGINT（占用8个字节），指针类型也一般为4或8个字节，也就是说一个页（B+Tree中的一个节点）中大概存储16KB/(8B+8B)=1K个键值（因为是估值，为方便计算，这里的K取值为〖10〗^3）。

实际中每个节点不能填充满，B+Tree的高度一般都在2~4层。MySQL的InnoDB存储引擎在设计时是将根节点常驻内存的，也就是说查找某一键值的行记录时最多只需要*1~3次磁盘I/O操作

回表与覆盖索引

• 针对非主键索引，都是先找到所在行的主键索引，再用主键索引查询。

——这就是回表（回到数据表再查一次的意思）

• 如果SQL只查询索引字段的值，那都不用去回表了，非主键索引的值再叶子节点中，已经找到了。

如：select a,b where a=1 and b=2，a和b有联合索引

>>>所以减少回表可以降低一半IO

4、事务与锁

ACID的实现方式
自动事务及手动事务
SQL92标准：事务隔离级别
InnoDB对事务隔离级别的支持与实现方式

5、性能优化