根据《MySQL技术内幕+InnoDB存储引擎》一书的学习记录
目录
根据《MySQL技术内幕+InnoDB存储引擎》一书的学习记录
1.1、关于数据库 与 数据库实例的理解，实例应该理解为管理这些数据的运行程序。
2.4.3 adaptive hash index: 自适应哈希索引
2.4.5 flush neighbor page:刷新临近页
2018/12/22 号记录
第一章：体系结构
1.1、关于数据库 与 数据库实例的理解，实例应该理解为管理这些数据的运行程序。
1.2、mysql体系结构
最底层都是文件系统，上面是存储引擎，主要学习的是 innodb 引擎，innodb引擎是基于 表的，它的表的数据是存在 ibd 文件之中。innodb使用MVCC 来达到高并发，同时较为突出的特性还有 插入缓冲，两次读，自适应hai哈希索引，预读 等。
innodb 存储采用 聚簇 的方式，表中存储的数据都是按照 主键 的顺序进行存储的，如果 在建立表的时候不存在 显示指定的主键，innodb 会 为每一个 元组 生成一个 6 字节的 ROWID 作为主键。
mysql的进程通信，网络的进程通信 有两种，socket 与 tcp/ip 连接， 本地进程通信 为 命名管道 与 共享内存。
第二章：innodb 存储引擎
2.1、关于后台线程
四种线程，master thread，IO thread， purge thread，page cleaner thread。
关于 IO thread：
purge thread：在事务被提交之后，需要回收 undo 日志文件页，通过这个线程完成。可是设置多个提高效率。
page cleaner thread ： 脏页刷新线程，减轻 master thread 的压力。
2.2、关于内存
加入 缓冲 池 机制，buffer pool。在缓冲池中的数据页 类型有：索引、数据、undo、插入缓冲、自适应哈希索引、锁信息、数据字典信息。允许 多个 缓冲池实例，哈希平均分配。自行配置。
LRU：修改缓冲的页，引入 checkpoint 机制，一定规律刷新到磁盘。通过 指定的（非直接加到头部 的）LRU 算法维护主要的索引页与数据页。每个 页 16KB。之后引入了 压缩页（略，暂时了解），Free LIst 空闲页列表，Flush List 脏页列表。
重做日志缓冲：redo log buffer，重做日志文件的缓冲。
额外的内存池： 数据结构自身的存储空间。
checkpoint：用于判断 何时 刷新脏页到磁盘的机制。关于数据有改变的过程：每次事务提交之前，先是对重做日志进行修改，先修改的是重做日志缓冲，之后的事务执行，修改其他的页数据（都先是缓冲修改），当脏页都被刷新到次磁盘中后，这部分的重做日志才会相当于失效，宕机后不会影响这部分的内容？？？但是后面也说，无论事务是否提交重做日志都会每秒刷新到磁盘，所以 checkpoint也需要在这里强制产生？？？
关于checkpoint 具体发生时间：？？？？？？？？？
2.3、Master Thread 工作方式（？没懂）
2.4、innodb 关键特性
2.4.1 insert buffer：
insert buffer 是物理页，不是在缓冲池中。
关于插入与更新操作，在缓冲池之下的层次，主要是更新索引页，插入或者更新节点。
插入缓冲的作用是针对非聚集的辅助索引。在进行插入操作的是，同时需要更新“所有”的索引页，即聚集索引的节点需要添加，非聚集的辅助索引（需要该索引来查询的）索引节点也需要插入（B+树）。数据页的存放还是按照主键顺序。针对聚集索引（主键）的是顺序的访问，但是针对辅助索引的节点插入时随机的，需要离散的访问非聚集索引页，导致性能下降。
缓冲池中有很多的非聚集索引页，如果需要添加的辅助索引对应的索引页在缓冲池，直接添加。不在则添加到insert buffer中，之后inser buffer 物理页与 对应的非聚集索引页进行子节点的合并操作（相当于另外一个索引的缓冲池，多个一次性刷新）。这样就会降低离散访问（根据辅助索引查询索引的时候需要遍历）的次数，问题：每张表都会有一个索引页？？？。并且插入的索引会相对顺序。
占用的是 缓冲池 的内存，但时实际是 物理页。不是缓冲池的组成部分？？？？
insert buffer 的升级版本是 change buffer:
insert buffer 的实现：
insert buffer 是使用 B+ 树的结构，现在的版本全局只有一个 insert buffer，放在共享表空间中，即 ibdata1。一个B+数即一部分的数据内存块，通过地址的不同寻址方式（每个内存空间都有对应的地址）形成的。
之后的 具体插入细节看不懂？？？？
合并 索引页：
2018/12/23记录
2.4.2 double write：
数据损坏问题：部分写失效问题，因为不同级别的IO单位不同，磁盘一个扇区大小 512 bytes，一个簇由很多的 扇区 组成，
对于文件系统的 IO 来说，一个文件需要占用多个簇，且一个簇 （8个扇区）只能有一个文件占用。所以针对一个文件系统 IO 的最小单位一般是 4 KB。
针对数据库来说，每个 页 的大小是 16 KB。
所以一个 脏页 刷线到 磁盘的时候，16 K 的页 需要 32 个扇区，所以在这个过程中发生了宕机，后果即是 页的 损坏。
insert buffer保证高效，double write 保证了数据的高可靠性。在写操作失效的时候，一般是通过 redo 日志进行重做，即从 缓冲池 刷新脏页到磁盘的时候，发生了宕机，通过 redo 日志 重做存在一个问题，即该磁盘的物理页损坏了，所以重做是没有用的，所以在刷新到脏页的时候，需要一个副本的存在。所以引入了 double write ，即刷新脏页的时候，首先copy到的double write buffer（内存实例中，不在缓冲池中） 中，先刷新到 （物理磁盘上）共享表空间的 double write的2MB上，之后再同步到磁盘，如果同步到磁盘的操作出错，那么通过 共享表空间连续的 128 个页（128x16=2MB = 1 MB + 1 MB）内存，先恢复到之前的状态再进行重做。
问题：既然 double write的内存中已经有了 最新的，为什么直接使用 redo 恢复到最新的情况？还是说需要体现 redo的作用？
https://www.cnblogs.com/geaozhang/p/7241744.html 网上没有说清楚。
2.4.3 adaptive hash index: 自适应哈希索引
自适应的哈希索引，针对 等值查找 的操作，如果某些查找模式 如 where a = 'xxx' 或者 where a='xxx' and b= 'xxx’ 的出现频率较高，那么存储引擎会针对这种模式，在B+树以外针对某些热点也建立哈希索引。比如一次查找先是根据B+树的索引 查到对应 索引的对应页，再去遍历对应的页。但是在B+树的查找上面花的时间可以通过哈希索引提高效率。
2.4.4 async IO:异步IO
2.4.5 flush neighbor page:刷新临近页
2.5、启动、关闭与恢复
通过 kill 命令模拟 数据库 服务 宕机，之后的数据库回滚。开启一个事务，更改数据，此时会修改undo逻辑日志，但是没有实际修改。此处见 书 2.7。
第三章 文件
3.1、参数文件：
键值对形式，动态静态参数两种类型
3.2、日志文件
3.2.1 error log：错误日志
记录在启动、运行、关闭时的错误信息，偶尔会给出解决方法，也记录警告语正确信息。
3.2.2 binlog：二进制日志
关于复制这部分，配置主从数据库，可以查看另外一篇博客。
其余部分看不明白。
3.2.3 slow query log：慢查询日志
1.设置一个时间的阈值，超过该阈值的SQL查询会被记录到 slow log中，供 DBA 优化。
2.一个相关的参数，表示SQL查询是否使用索引，没有使用的也会被记录。
3.新的版本有一个表示每分钟未使用索引的SQL被记录的最大数目，一般无限制。
慢查询日志过大后，DBA使用 mysqldumpslow 命令查询日志的某些特定的记录
新的版本建立了 slow_log 表格，使用的引擎不是 innodb。被建议使用MyISAM。
3.2.4 log：查询日志
3.3、套接字文件
此部分是关于网络连接数据库内容。
3.4、pid 文件
3.5、表结构定义文件
每个表都对应有文件
3.6、Innodb 存储引擎文件
之前的都是数据库本身的文件，后面的是关于存储引擎的文件，包括 表空间 文件 与 重做日志redo文件。
3.6.1 表空间文件：
一个表涉及到：idb独立表空间文件、默认的共享表空间文件、.frm表结构定义文件。
3.6.2 redo log 文件：
写入文件的过程：
此处不需要 double write 因为写入不会存在 也损坏的情况，情况磁盘IO的单位 512 bytes 远小于 页的大小。但是 redo 刷新到 磁盘的时候，是按照 512 字节的形式去刷新的，所以写入一定是成功的。
其余关于一些 关键 参数的空间，确定 redo 开启的时期与其余的级别空间已忽略。
总结：
时隔一个月的样子了，有时间开始看 这本书的 第二遍，没出细节都会去试验一下，认识到了更深层的东西。继续加油。