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、性能优化
