引子
陆陆续续花了将近半个月把这本书看完了，全书一共分为10大章节，其中挑了自己觉得比较有意思的章节进行阅读，分别是
- 第一章 Mysql体系结构和存储引擎
- 第二章 InnoDB存储引擎
- 第五章 索引与算法
- 第六章 锁
上面没列下来的章节，有些是涉及到文件存储、性能调优参数的，感觉并不是很重要，就简单的翻翻留个印象就略过了。
总体来说，读完这本书后，能对Innodb存储引擎有个大概的认识，能初略了解其实现原理。里面很多原理设计都是十分经典，很值得学习。
Mysql体系结构和存储引擎
首先是第一章，简单介绍了Mysql的体系架构。
可以看出来，Mysql表存储引擎是做成插件化的，可选择性很多。与其他数据库相比，InnoDB有以下特点
- 支持事务
- 支持行级锁
- 支持非锁定读(默认读取操作不会产生锁)
InnoDB存储引擎
先看一下InnoDB的简单体系图
从图中可以看到，InnoDB的体系简单分为三块，分别是后台线程，内存池，文件。
后台线程
后台线程主要作用
- 是刷新内存池中的数据，保证缓冲池中数据都是最新的数据。
- 将缓冲池中的数据刷刷新到磁盘文件中.
- 保证发生异常时候，发生缓冲池和磁盘数据不一致时能正常恢复。
后台线程分为
- Master Thread - 核心线程，负责缓冲池数据刷回磁盘，脏页刷新，合并插入缓冲，UNDO页回收等。
- IO Thread - 负责AIO的回调处理
- Purge Thread - 回收已经没有用的UNDO页(从Master Thread抽离)
- Page Cleaner Thread - 脏页刷新回磁盘(从Master Thread抽离)
IO Thread
关于第二点IO Thread，会使用AIO呢？有两个好处
第一是因为一个SQL的查询，可能需要读取磁盘中的多个索引页，AIO可以并行读取数据，，提高读取的效率。
第二是可以进行IO合并操作，当读取的多个页是相邻的，可以合并为一个IO请求，提高IOPS。
// TODO AIO的实现由Linux内核支持，但是具体的实现原理，还有待后续探究。
缓冲池
我们都知道内存操作的速度是远远大于磁盘操作速度的。所以Innodb采用缓冲池来提高数据库的性能。
页的读取
数据库读取页的时候，会先判断缓冲池中是否已经存在该页，如果存在，就直接使用缓冲池中的页，如果不存在，就从磁盘中进行读取。
页的修改
对于页的修改，也是先修改缓冲池中的页，然后再以一定的频率刷新到磁盘进行持久化。
如果数据在刷回磁盘前数据库异常了怎么办？答案是根据Redo日志进行恢复。InnoDB会保证，在页修改时，Redo日志必须已经持久化到磁盘。
页的管理
InnoDB使用LRU来管理缓冲中的页，朴素的LRU会把最新的数据插入到头部，淘汰掉尾部的数据。InnoDB使用的LRU有一点不同的是，最新的数据会插入到中间的位置，这是为了避免一些冷门的大SQL需要扫描很多页，导致热点数据被刷掉。
重做日志缓冲
在上面页的修改中提到过，重做日志信息会先放到重做日志缓冲区，然后按照一定的频率刷回磁盘文件，通常情况下，这三种情况会触发刷新。
- Master Thread每一秒将重做日志刷新
- 事物提交
- 重做日志缓冲池空间少于1/2(默认为8m)
Check Point(检查点)
CheckPoint可以理解为检查点，每到检查点，缓冲池中的脏页数据会马上刷回到磁盘。
- Master Thread Checkpoint - 每秒或十秒一次
- FLUSH_LRU_LIST Checkpoint - LRU空间页不足时
- Async/Sync Flush Checkpoint - 重做日志不可用时
Master Thread工作方式
Master Thread上面简单提到过，会处理负责缓冲池数据刷回磁盘，脏页刷新，合并插入缓冲，UNDO页回收等。下面简单说一下它的功能。
每秒一次的
- 日志缓冲刷新到磁盘
- 合并插入缓冲
- 刷新100个InnoDB缓冲池中的脏页到磁盘
即使事务还没有提交，InnoDB仍然会每秒将重做日志缓冲内容刷新到重做日志文件，所以即使是很大的事务也能快速提交。
每十秒一次的
- 刷新100个脏页到磁盘
- 合并至多5个插入缓冲
- 将日志缓冲刷新到磁盘
- 删除无用的Undo页
插入缓冲
先解释一下插入缓冲，插入缓冲指的是非聚簇索引的插入方式是先缓冲到内存中，一段时间后再刷新到磁盘文件里面的。
插入缓冲需要满足两个条件
- 非唯一，因为唯一在插入时需要判断约束，无法缓冲
- 索引是非聚簇索引
为什么要这么处理呢？我们知道InnoDB是用B+Tree的索引结构来存储数据的，我们一般会使用自增长的ID作为主键，因为其是自增的，所以在磁盘文件中，写入的数据地址在磁盘中都是顺序的，但是非聚簇索引在存储结构上并不是连续的，这时候需要离散地读取非聚簇索引页，造成插入的性能下降。
两次写（Double Write）
缓冲池中脏页在写入磁盘时，可能会受到宕机的影响导致脏页数据未完全写入磁盘，导致数据丢失。
为了解决这个问题，Innodb引入了double-write机制。
double-write的流程是，脏页数据会先写入double-write缓冲区中(doublewrite-buffer)，然后doublewrite-buffer中数据会写入共享空间磁盘，写入成功后，才会真正写入到数据存储的磁盘中。
如果在写入数据存储磁盘时发生意外宕机，磁盘中数据只写入了一部分，mysql会从共享空间磁盘中直接将该页数据复制到数据存储磁盘。
关于doublewrite的性能影响其实并不大，原因是第一是脏页中一般会有很多数据同时刷新到磁盘，Innodb会将这些操作进行合并操作，减少fsync的操作次数。第二是写入共享空间时是顺序写入的。
自适应Hash索引
InnoDB的自优化，InnoDB会监控表上索引页的查询，如果发现建立hash索引可以带来速度提升，就会建立哈希索引。
前提是确定的查询条件(where a=xxx)，范围查询不适用(where a > xxx)。
表
这章简单略过，主要是介绍表的存储结构。主要看下图就可以了。InnoDB的数据结构都是用B+Tree来组织的。
粒度从左到右逐渐变细，需要注意的是页是InnoDB管理磁盘的最小单位，InnoDB从磁盘中读数据都是按页读的。
tablespace(表空间) -> segment(段) -> extend(区) -> page(页) -> row(行)
索引与算法
InnoDB支持三种索引，分别是B+树索引，全文索引，Hash索引。全文索引和Hash索引就不详细些了，主要写B+树索引。
B+树
上图是书中举例的一棵B+树，可以看下它有以下特点
- 所有数据都在叶子节点，非叶子节点不存储数据
- 叶子节点使用双向链表链接
然后，为什么会使用B+树来组织索引数据呢？
- 非叶子节点也是由页组成，每个页的大小是有限的，而B+树非叶子节点不存储真实数据，使得非叶子节点可以放入非常多的索引数据，降低树的层数。而树的层数越低，扫描索引数据需要的次数也就越低。
- 数据都放在叶子节点中，每次索引扫描，需要进行IO磁盘次数都是一致的，所以每次扫描的时间都十分稳定。
- 叶子节点使用双向链表链接，可以很方便地进行范围查询。
所以，为什么DBA老是跟我们说不要用大VARCHAR建立索引呢？用长的VARCHAR建立索引，页能存储的数据数目就变少了，效率自然就降低了。
聚簇索引
聚簇索引就是按照表主键构建的B+Tree，叶子节点存储的就是表的行记录数据。
非聚簇索引
叶子节点不包含行的记录数据，而是存储聚餐索引的聚簇索引键，一般就是主键。
当通过非聚簇索引查找数据时，需要先在非聚簇索引树中找到对应的聚簇索引键，然后再根据键到聚簇索引树中查找数据。
所以也不要认为建一个非聚簇索引就万事大吉了，如果在非聚簇索引键上进行大范围的数据查询，还是得离散地访问聚簇索引树，效率不一定比全表扫描快。
联合索引
略
覆盖索引
略
MRR技术(Multi-Range Read)
Mysql5.5.6后支持的，目的是减少磁盘的随机访问，将随机访问转换为较为顺序的数据访问。
工作方式为
- 将查询得到的非聚簇索引键值存储到一个缓存中
- 缓存中的键值进行排序，再根据排序的顺序进行数据访问
如果多个键值在同一个页里面，就能一次磁盘访问就把数据捞出来了。
ICP优化(Index Condition Pushdown)
这个也是Mysql5.6后支持的。举一个例子进行了解
# index为product_id
# id为主键
select * from order where product_id = 'xxx' and order_detail like '%xxx%' and create_time like '%xxxx-xx-xx%'如果没有开启ICP优化，数据库会先通过product_id找出所有的数据，然后再过滤where后的条件。
若支持了ICP优化，则会在索引取出时候，就会进行where条件的过滤。
// 其实感觉这个优化对我们目前来说有点鸡肋，书中举的例子，得需要主键是联合索引才行，比如上面的例子，如果主键为(id, order_detail)，那数据库通过product_id获取到聚簇索引主键时候，也就能同时得到order_detail，这时候就能根据where条件去掉不符合条件的order_detail数据，减少符合的索引键数目，效率自然就提升了，但是平时我们建表的时候主键都不会这么建。
锁
标准锁
InnoDB实现了两种标准的行级锁
- 共享锁(S Lock)，允许事务读一行数据
- 排它锁(X Lock)，允许事务删除或更新一条数据
S锁与S锁是兼容的，意思是当一条记录被S锁锁住的时候，可以继续往上面加S锁，但是S锁和X锁是互斥的，两者同时只能存在一个锁锁住记录。
# 共享锁写法
select * from table where a=1 in share mode
# 排它锁写法
select * from table where a=1 for update除了这两种锁，InnoDB还有意向锁，分别为意向共享锁（IS Lock）和意向排它锁(IX Lock)，这个锁的作用是，当事务要对细粒度的记录加锁时，会先从粗粒度开始往下加意向锁，如果碰到锁不兼容的情况就进行等待。通过意向锁，InnoDB支持了多粒度锁定(即表锁和行锁可以共存)
一致性非锁定读
简单来说，就是Mysql的普通查询语句，是不需要加锁的。如果查询中的数据刚好被锁了，这时候查询语句会查记录的快照版本，从而不需要等待行锁释放就能查询到记录。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
