MySQL学习笔记之数据库结构

MySQL学习笔记

（一）数据库支持的存储引擎

1. MyISAM
   应用范围比较小。表级锁定限制了读/写的性能，因此在Web 和数据仓库配置中，
   它通常用于只读或以读为主的工作。
   特点：
   1.支持表级别的锁（插入和更新会锁表），不支持事务。
   2.拥有较高的插入（insert）和查询（select）速度。
   3.存储了表的行数（count 速度更快）。
   （怎么快速向数据库插入100 万条数据？我们有一种先用MyISAM 插入数据，然后修改存储引擎为InnoDB 的操作。）
   适合：只读之类的数据分析的项目。
2. InnoDB
   mysql 5.7 中的默认存储引擎。InnoDB 是一个事务安全（与ACID 兼容）的MySQL
   存储引擎，它具有提交、回滚和崩溃恢复功能来保护用户数据。InnoDB 行级锁（不升级为更粗粒度的锁）和Oracle 风格的一致非锁读提高了多用户并发性和性能。InnoDB 将用户数据存储在聚集索引中，以减少基于主键的常见查询的I/O。为了保持数据完整性，InnoDB 还支持外键引用完整性约束。
   特点：
   1.支持事务，支持外键，因此数据的完整性、一致性更高。
   2.支持行级别的锁和表级别的锁。
   3.支持读写并发，写不阻塞读（MVCC）。
   4.特殊的索引存放方式，可以减少IO，提升查询效率。
   适合：经常更新的表，存在并发读写或者有事务处理的业务系统。

如何选择存储引擎？
　　如果对数据一致性要求比较高，需要事务支持，可以选择InnoDB。
　　如果数据查询多更新少，对查询性能要求比较高，可以选择MyISAM。
　　如果需要一个用于查询的临时表，可以选择Memory。
　　如果所有的存储引擎都不能满足你的需求，并且技术能力足够，可以根据官网内部手册用C 语言开发一个存储引擎：
　　https://dev.mysql.com/doc/internals/en/custom-engine.html

（二）MySQL 体系结构总结

基于上面分析的流程，我们一起来梳理一下MySQL 的内部模块。

2.1 模块详解

• Connector：用来支持各种语言和SQL 的交互，比如PHP， Python，Java 的JDBC；
• Management Serveices & Utilities：系统管理和控制工具，包括备份恢复、MySQL 复制、集群等等；
• Connection Pool：连接池，管理需要缓冲的资源，包括用户密码权限线程等等；
• SQL Interface：用来接收用户的SQL 命令，返回用户需要的查询结果
• Parser：用来解析SQL 语句；
• Optimizer：查询优化器；
• Cache and Buffer：查询缓存，除了行记录的缓存之外，还有表缓存，Key 缓存，权限缓存等等；
• Pluggable Storage Engines：插件式存储引擎，它提供API 给服务层使用，跟具体的文件打交道。

2.2 架构分层

总体上，我们可以把MySQL 分成三层，跟客户端对接的连接层，真正执行操作的服务层，和跟硬件打交道的存储引擎层（参考MyBatis：接口、核心、基础）。

2.2.1 连接层

我们的客户端要连接到MySQL 服务器3306 端口，必须要跟服务端建立连接，那么管理所有的连接，验证客户端的身份和权限，这些功能就在连接层完成。

2.1.2.服务层

连接层会把SQL 语句交给服务层，这里面又包含一系列的流程：
　比如查询缓存的判断、根据SQL 调用相应的接口，对我们的SQL 语句进行词法和语法的解析（比如关键字怎么识别，别名怎么识别，语法有没有错误等等）。
　然后就是优化器，MySQL 底层会根据一定的规则对我们的SQL 语句进行优化，最后再交给执行器去执行。

2.1.3.存储引擎

存储引擎就是我们的数据真正存放的地方，在MySQL 里面支持不同的存储引擎。
再往下就是内存或者磁盘。

（三）数据操作

3.1. 缓冲池Buffer Pool

首先，InnnoDB 的数据都是放在磁盘上的，InnoDB 操作数据有一个最小的逻辑单位，叫做页（索引页和数据页）。我们对于数据的操作，不是每次都直接操作磁盘，因为磁盘的速度太慢了。InnoDB 使用了一种缓冲池的技术，也就是把磁盘读到的页放到一块内存区域里面。这个内存区域就叫Buffer Pool。

　 下一次读取相同的页，先判断是不是在缓冲池里面，如果是，就直接读取，不用再次访问磁盘。
　修改数据的时候，先修改缓冲池里面的页。内存的数据页和磁盘数据不一致的时候，我们把它叫做脏页。InnoDB 里面有专门的后台线程把Buffer Pool 的数据写入到磁盘，每隔一段时间就一次性地把多个修改写入磁盘，这个动作就叫做刷脏。
Buffer Pool 是InnoDB 里面非常重要的一个结构，它的内部又分成几块区域。这里我们趁机到官网来认识一下InnoDB 的内存结构和磁盘结构。

3.2. InnoDB 内存结构和磁盘结构

3.2.1.内存结构

Buffer Pool 主要分为3 个部分： Buffer Pool、Change Buffer、Adaptive Hash Index，另外还有一个（redo）log buffer。

3.2.1.1. Buffer Pool

Buffer Pool 缓存的是页面信息，包括数据页、索引页。
查看服务器状态，里面有很多跟Buffer Pool 相关的信息：

SHOW STATUS LIKE ‘%innodb_buffer_pool%’;

这些状态都可以在官网查到详细的含义，用搜索功能。
https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html

Buffer Pool 默认大小是128M（134217728 字节），可以调整。
查看参数（系统变量）：

SHOW VARIABLES like ‘%innodb_buffer_pool%’;

这些参数都可以在官网查到详细的含义，用搜索功能。
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html

内存的缓冲池写满了怎么办？（Redis 设置的内存满了怎么办？）
　InnoDB 用LRU算法来管理缓冲池（链表实现，不是传统的LRU，分成了young 和old），经过淘汰的数据就是热点数据。

内存缓冲区对于提升读写性能有很大的作用。
思考一个问题：
　当需要更新一个数据页时，如果数据页在Buffer Pool 中存在，那么就直接更新好了。否则的话就需要从磁盘加载到内存，再对内存的数据页进行操作。也就是说，如果没有命中缓冲池，至少要产生一次磁盘IO，有没有优化的方式呢？

3.2.1.2. Change Buffer 写缓冲

如果这个数据页不是唯一索引，不存在数据重复的情况，也就不需要从磁盘加载索引页判断数据是不是重复（唯一性检查）。这种情况下可以先把修改记录在内存的缓冲池中，从而提升更新语句（Insert、Delete、Update）的执行速度。
　这一块区域就是Change Buffer。5.5 之前叫Insert Buffer 插入缓冲，现在也能支持delete 和update。
　 最后把Change Buffer 记录到数据页的操作叫做merge。什么时候发生merge？
有几种情况：在访问这个数据页的时候，或者通过后台线程、或者数据库shut down、redo log 写满时触发。
　如果数据库大部分索引都是非唯一索引，并且业务是写多读少，不会在写数据后立
刻读取，就可以使用Change Buffer（写缓冲）。写多读少的业务，调大这个值：

SHOW VARIABLES LIKE ‘innodb_change_buffer_max_size’;

代表Change Buffer 占Buffer Pool 的比例，默认25%。

3.2.1.3、Adaptive Hash Index

索引应该是放在磁盘的，为什么要专门把一种哈希的索引放到内存？

3.2.1.4、（redo）Log Buffer

思考一个问题：
　　如果Buffer Pool 里面的脏页还没有刷入磁盘时，数据库宕机或者重启，这些数据丢失。如果写操作写到一半，甚至可能会破坏数据文件导致数据库不可用。

为了避免这个问题，InnoDB 把所有对页面的修改操作专门写入一个日志文件，并且在数据库启动时从这个文件进行恢复操作（实现crash-safe）——用它来实现事务的持久性。

　这个文件就是磁盘的redo log（叫做重做日志），对应于/var/lib/mysql/目录下的ib_logfile0 和ib_logfile1，每个48M。
　这种日志和磁盘配合的整个过程， 其实就是MySQL 里的WAL 技术（Write-Ahead Logging），它的关键点就是先写日志，再写磁盘。

show variables like ‘innodb_log%’;

值	含义
innodb_log_file_size	指定每个文件的大小，默认48M
innodb_log_files_in_group	指定文件的数量，默认为2
innodb_log_group_home_dir	指定文件所在路径，相对或绝对。如果不指定，则为datadir 路径。

问题：
　同样是写磁盘，为什么不直接写到db file 里面去？为什么先写日志再写磁盘？
　我们先来了解一下随机I/O 和顺序I/O 的概念。
　磁盘的最小组成单元是扇区，通常是512 个字节。
　操作系统和内存打交道，最小的单位是页Page。
　操作系统和磁盘打交道，读写磁盘，最小的单位是块Block。

　如果我们所需要的数据是随机分散在不同页的不同扇区中，那么找到相应的数据需
要等到磁臂旋转到指定的页，然后盘片寻找到对应的扇区，才能找到我们所需要的一块
数据，一次进行此过程直到找完所有数据，这个就是随机IO，读取数据速度较慢。
　假设我们已经找到了第一块数据，并且其他所需的数据就在这一块数据后边，那么就不需要重新寻址，可以依次拿到我们所需的数据，这个就叫顺序IO。
　刷盘是随机I/O，而记录日志是顺序I/O，顺序I/O 效率更高。因此先把修改写入日
志，可以延迟刷盘时机，进而提升系统吞吐。
　当然redo log 也不是每一次都直接写入磁盘，在Buffer Pool 里面有一块内存区域
（Log Buffer）专门用来保存即将要写入日志文件的数据，默认16M，它一样可以节省
磁盘IO。

HOW VARIABLES LIKE ‘innodb_log_buffer_size’;

需要注意：redo log 的内容主要是用于崩溃恢复。磁盘的数据文件，数据来自buffer
pool。redo log 写入磁盘，不是写入数据文件。
那么，Log Buffer 什么时候写入log file？
在我们写入数据到磁盘的时候，操作系统本身是有缓存的。flush 就是把操作系统缓
冲区写入到磁盘。
log buffer 写入磁盘的时机，由一个参数控制，默认是1。

SHOW VARIABLES LIKE ‘innodb_flush_log_at_trx_commit’;

　　这是内存结构的第4 块内容，redo log，它又分成内存和磁盘两部分。redo log 有
什么特点？
1、redo log 是InnoDB 存储引擎实现的，并不是所有存储引擎都有。
2、不是记录数据页更新之后的状态，而是记录这个页做了什么改动，属于物理日志。
3、redo log 的大小是固定的，前面的内容会被覆盖。
check

　　check point 是当前要覆盖的位置。如果write pos 跟check point 重叠，说明redo
log 已经写满，这时候需要同步redo log 到磁盘中。
　　这是MySQL 的内存结构，总结一下，分为：
Buffer pool、change buffer、Adaptive Hash Index、log buffer。

磁盘结构里面主要是各种各样的表空间，叫做Table space。

3.2.２.磁盘结构

表空间可以看做是InnoDB 存储引擎逻辑结构的最高层，所有的数据都存放在表空间中。InnoDB 的表空间分为5 大类。

• 系统表空间system tablespace
  在默认情况下InnoDB 存储引擎有一个共享表空间（对应文件/var/lib/mysql/ibdata1），也叫系统表空间。
  　InnoDB 系统表空间包含InnoDB 数据字典和双写缓冲区，Change Buffer 和Undo Logs），如果没有指定file-per-table，也包含用户创建的表和索引数据。
  　1、undo 在后面介绍，因为有独立的表空间。
  　2、数据字典：由内部系统表组成，存储表和索引的元数据（定义信息）。
  　3、双写缓冲（InnoDB 的一大特性）：
  　InnoDB 的页和操作系统的页大小不一致，InnoDB 页大小一般为16K，操作系统页大小为4K，InnoDB 的页写入到磁盘时，一个页需要分4 次写。
  　
  　如果存储引擎正在写入页的数据到磁盘时发生了宕机，可能出现页只写了一部分的情况，比如只写了4K，就宕机了，这种情况叫做部分写失效（partial page write），可能会导致数据丢失。
  　show variables like ‘innodb_doublewrite’;
  　我们不是有redo log 吗？但是有个问题，如果这个页本身已经损坏了，用它来做崩溃恢复是没有意义的。所以在对于应用redo log 之前，需要一个页的副本。如果出现了写入失效，就用页的副本来还原这个页，然后再应用redo log。这个页的副本就是***double　write***，InnoDB 的双写技术。通过它实现了数据页的可靠性。
  　跟redo log 一样，double write 由两部分组成，一部分是内存的double write，一个部分是磁盘上的double write。因为double write 是顺序写入的，不会带来很大的开销。
  　在默认情况下，所有的表共享一个系统表空间，这个文件会越来越大，而且它的空间不会收缩。
• 独占表空间file-per-table tablespaces
  我们可以让每张表独占一个表空间。这个开关通过innodb_file_per_table 设置，默认开启。
  SHOW VARIABLES LIKE ‘innodb_file_per_table’;
  开启后，则每张表会开辟一个表空间，这个文件就是数据目录下的ibd 文件（例如/var/lib/mysql/gupao/user_innodb.ibd），存放表的索引和数据。
  　但是其他类的数据，如回滚（undo）信息，插入缓冲索引页、系统事务信息，二次写缓冲（Double write buffer）等还是存放在原来的共享表空间内。
• 通用表空间general tablespaces
  通用表空间也是一种共享的表空间，跟ibdata1 类似。
  　可以创建一个通用的表空间，用来存储不同数据库的表，数据路径和文件可以自定义。语法：
  　create tablespace ts2673 add datafile ‘/var/lib/mysql/ts2673.ibd’ file_block_size=16K engine=innodb;
  　在创建表的时候可以指定表空间，用ALTER 修改表空间可以转移表空间。
  　36
  一个部分是磁盘上的double write。因为double write 是顺序写入的，不会带来很大的
  开销。
  在默认情况下，所有的表共享一个系统表空间，这个文件会越来越大，而且它的空
  间不会收缩。
  独占表空间file-per-table tablespaces
  我们可以让每张表独占一个表空间。这个开关通过innodb_file_per_table 设置，默
  认开启。
  SHOW VARIABLES LIKE ‘innodb_file_per_table’;
  开启后，则每张表会开辟一个表空间，这个文件就是数据目录下的ibd 文件（例如
  /var/lib/mysql/gupao/user_innodb.ibd），存放表的索引和数据。
  但是其他类的数据，如回滚（undo）信息，插入缓冲索引页、系统事务信息，二次
  写缓冲（Double write buffer）等还是存放在原来的共享表空间内。
  通用表空间general tablespaces
  通用表空间也是一种共享的表空间，跟ibdata1 类似。
  可以创建一个通用的表空间，用来存储不同数据库的表，数据路径和文件可以自定
  义。语法：
  create tablespace ts2673 add datafile ‘/var/lib/mysql/ts2673.ibd’ file_block_size=16K engine=innodb;
  在创建表的时候可以指定表空间，用ALTER 修改表空间可以转移表空间。
  create table t2673(id integer) tablespace ts2673;
  不同表空间的数据是可以移动的。
  删除表空间需要先删除里面的所有表：
  drop table t2673;
  drop tablespace ts2673;
• 临时表空间temporary tablespaces
  存储临时表的数据，包括用户创建的临时表，和磁盘的内部临时表。对应数据目录下的ibtmp1 文件。当数据服务器正常关闭时，该表空间被删除，下次重新产生。
• Redo log
  磁盘结构里面的redo log，在前面已经介绍过了。
• undo log tablespace
  undo log（撤销日志或回滚日志）记录了事务发生之前的数据状态（不包括select）。
  　如果修改数据时出现异常，可以用undo log 来实现回滚操作（保持原子性）。
  　在执行undo 的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，属于逻辑格式的日志。
  　redo Log 和undo Log 与事务密切相关，统称为事务日志。
  　undo Log 的数据默认在系统表空间ibdata1 文件中，因为共享表空间不会自动收缩，也可以单独创建一个undo 表空间。
  show global variables like ‘%undo%’;
  有了这些日志之后，我们来总结一下一个更新操作的流程，这是一个简化的过程。
  name 原值是qingshan。
  update user set name = ‘penyuyan’ where id=1;
  1、事务开始，从内存或磁盘取到这条数据，返回给Server 的执行器；
  2、执行器修改这一行数据的值为penyuyan；
  3、记录name=qingshan 到undo log；
  4、记录name=penyuyan 到redo log；
  5、调用存储引擎接口，在内存（Buffer Pool）中修改name=penyuyan；
  6、事务提交。

3.2.３.后台线程

（供了解）
后台线程的主要作用是负责刷新内存池中的数据和把修改的数据页刷新到磁盘。后台线程分为：master thread，IO thread，purge thread，page cleaner thread。
　master thread 负责刷新缓存数据到磁盘并协调调度其它后台进程。
IO thread 分为insert buffer、log、read、write 进程。分别用来处理insert buffer、重做日志、读写请求的IO 回调。
　purge thread 用来回收undo 页。
　page cleaner thread 用来刷新脏页。

3.3. Binlog

除了InnoDB 架构中的日志文件，MySQL 的Server 层也有一个日志文件，叫做binlog，它可以被所有的存储引擎使用。
binlog 以事件的形式记录了所有的DDL 和DML 语句（因为它记录的是操作而不是数据值，属于逻辑日志），可以用来做主从复制和数据恢复。
　跟redo log 不一样，它的文件内容是可以追加的，没有固定大小限制。
　在开启了binlog 功能的情况下，我们可以把binlog 导出成SQL 语句，把所有的操作重放一遍，来实现数据的恢复。
binlog 的另一个功能就是用来实现主从复制，它的原理就是从服务器读取主服务器的binlog，然后执行一遍。
　有了这两个日志之后，我们来看一下一条更新语句是怎么执行的：
　
　例如一条语句：update teacher set name=‘盆鱼宴’ where id=1;
　1、先查询到这条数据，如果有缓存，也会用到缓存。
　2、把name 改成盆鱼宴，然后调用引擎的API 接口，写入这一行数据到内存，同时记录redo log。这时redo log 进入prepare 状态，然后告诉执行器，执行完成了，可以随时提交。
　3、执行器收到通知后记录binlog，然后调用存储引擎接口，设置redo log 为commit
状态。
　4、更新完成。
　
　这张图片的重点（没必要背下来）：
1、先记录到内存，再写日志文件。
2、记录redo log 分为两个阶段。
3、存储引擎和Server 记录不同的日志。
3、先记录redo，再记录binlog。