MySQL 读书笔记（一） 体系结构

感觉好久没有看MySQL相关的书了，最近边复习，边整理下感觉重要的知识点，一点点的由简入繁，先从整体概念上理解下，扩充下整个知识图谱。

一、MySQL 体系结构

基础中有两个重要概念，数据库和数据库实例。

数据库：文件的集合，依照某种数据模型组织并存放于二级存储器中的数据集合。

数据库实例：是程序，位于用户与操作系统之间的一层数据库管理软件，用户对于数据库的任何操作（DML，DDL）都是在数据库实例下进行的，应用程序只有通过数据库实例才能和数据库打交道。

看了，最开始的架构图，可以了解到MySQL 由以下组成

1、连接池组件

2、管理和工具组件

3、接口组件

4、解析器组件

5、优化器组件

6、缓存组件

7、插件式的存储引擎

8、物理文件

注意：存储引擎是基于表，而不是数据库

二、存储引擎

下面介绍几个重要的存储引擎的特点

1、InnoDB

特点：

• 支持事物，主要面向在线数据处理OLTP

• 支持行锁设计

  • 分为共享锁和排它锁
  • 行锁有基本的三种算法    
            - record: 使用 ‘=’ 符号时，只查询一行记录的时候。
            - Gap: 记录不存在的时候退化为这个，相同间隙锁不冲突， 查询id>20 其实也有可能锁住11 ，因为整个间隙都加锁
    • Next key: Gap + record

• 支持外健.

• 使用next-key locking的策略来避免幻读

• 通过多版本并发控制（MVCC）获得高并发性，并实现了4种隔离级别，默认REPEATABLE.

• 插入缓冲（insert buffer）

  • 插入缓冲,并不是缓存的一部分,而是物理页,对于非聚集索引的插入或更新操作,不是每一次直接插入索引页.而是先判断插入的非聚集索引页是否在缓冲池中.如果在,则直接插入,如果不再,则先放入一个插入缓冲区中.然后再以一定的频率执行插入缓冲和非聚集索引页子节点的合并操作

• 二次写（double write）

  • InnoDB 的Page Size一般是16KB，其数据校验也是针对这16KB来计算的，将数据写入到磁盘是以Page为单位进行操作的。而计算机硬件和操作系统，在极端情况下（比如断电）往往并不能保证这一操作的原子性，16K的数据，写入4K 时，发生了系统断电/os crash ，只有一部分写是成功的，这种情况下就是 partial page write 问题.
  • 所以简单的说就是，在将数据写盘的时候断电了，一部分数据丢失后，根本不能从redo log来进行恢复了。其原理是在写数据页之前，先把这个数据页写到一块独立的物理文件位置（ibdata），然后再写到数据页。在宕机重启后，先通过该副本还原数据页，在使用redo log.

• 自适应哈希索引

  • nnoDB采用自适用哈希索引技术，它会实时监控表上索引的使用情况，如果认为建立哈希索引可以提高查询效率，则自动在内存中的“自适应哈希索引缓冲区建立哈希索引

• 预读

  • 分为线性预读和随机预读

存储其采用了聚集的方式，因此数据都是顺序存储，如没有显示的指定主键，会为每一行数据生成一个6字节的ROWID作为主键

2、MyISAM

不支持事物，表锁设计，支持全文检索，主要面向OLAP

缓冲池之缓存索引文件不缓冲数据

表由MYD 和MYI 组成，MYD存储数据，MYI 存储索引文件

3、NDB

集群存储引擎类似Oracle的RAC集群

数据全部存放在内存中

（JOIN）连接操作是在mysql数据库层完成的，而不是存储引擎层完成。（复杂的连接操作需要巨大的网络开销，因此查询巨慢）

4、Memory

表中数据存放在内存中，重启数据消失

适用于临时数据的临时表，数据仓库维度表。

默认是哈希索引，而不是B+树索引

只支持表锁，并发性能差，并不支持TEXT和BLOB类型。

存储变长字段（varchart）时，是按照定长字段（char）方式进行，因此会浪费内存

如果MYSQL数据库使用MEMORY存储引擎作为临时表来存放查询的中间结果集。如果结果集大于Memory存储引擎设置的容量，又或者其中包含TEXT 和BLOB 数据类型字段，则MySQL数据库会把其转换到MYISAM存储引擎表而存放到磁盘中。因M有ISAM不缓存数据文件，所以临时表的查询会损失性能。

先整体回顾了下大概的结构和知识点，下周主要针对InnoDB 做一个完整性的细节回顾