mysql技术内幕-innodb 思维导图模板_ProcessOn思维导图、流程图

索引和算法

innodb的索引

Cardinality

表示索引中不重复记录数量的预付值，尽可能接近1，如果非常小，说明该索引列中的重复数据很多，而对取值范围很小的列设置索引的意义不大（如对性别列设置索引）

为了监控一个列是否适合建立索引，需要参考 cardinality 的值，而这个值需要进行统计才能得出，但是如果对所有的数据都统计则非常消耗性能，所以数据库对 cardinality 的统计都是通过采样完成的

在 insert/update 时统计

表中1/16的数据发生变化

stat_modified_counter>2000000000

B+树索引

结构

主索引

非主索引

首先，每个叶子节点存储了主键的值；对于非叶子节点，不仅存储了索引字段的值，同时也存储了对应的主键的最小值

B+树的插入和删除

B+树索引发分裂

索引的管理

查看索引信息show index

cardinality
非常关键的值，表示索引中唯一值的数据的估计值。应该尽可能的接近1，如果非常小，可以考虑去掉该索引

alter table add/drop index

可以只对一个列的开头部分数据进行索引，alter table add key idx_b (b((100))

聚集索引

按照没涨表的主键构造一棵B+树，同时叶子节点中存放的即为整张表的行记录数据，也将聚集索引的叶子节点称为数据页
非叶子节点的索引页中，存放的仅仅是键值及指向数据页的偏移量，而不是一个完整的行记录

辅助索引

叶子节点存放索引的键值对，不包含行记录的全部数据，但包含一个告诉 innodb 引擎哪里可以找到与索引相对应行数据的书签（bookmark）

当通过辅助索引来寻找数据时，Innodb 存储引擎会遍历辅助索引并通过叶级别的指针获得指向主键索引的主键，然后再通过主键索引来找到一个完整的行记录

联合索引

对表上的多个列进行索引

覆盖索引

Innodb存储引擎支持覆盖索引，即从辅助索引中就可以得到查询的记录而不需要查找聚集索引中的记录

覆盖索引不包含整行的数据，其大小远小于聚集索引，所以可以减少IO次数

优化器不使用指定索引的情况

一般发生再 sql 指定查询条件包含辅助索引但是实际上SQL执行器却没通过辅助索引查找数据

执行EXplain 命令进行 sql分析时，会发现优化器并没有选择索引去查找数据，而是通过扫描聚集索引，直接进行全表的扫描来得到数据

多反生于范围查找、Join 连接操作

当SQL查找的字段刚好是索引列，或者查找全部的字段但通过索引查找的数量只是少数时，优化器会选择使用索引列查找，这种情况和索引覆盖类似

但是如果查找的字段不全部在索引中，而且方位的数据占比较大（20%）时，会考虑放弃使用索引而使用表扫描（即扫描全表数据）
这是因为通过辅助索引直接得到的数据只包括本身值和指向真实数据页的书签，想要获取其他字段还需要通过读取数据页才能得到，但是因为辅助页获取的数据页不是连续的，这样就造成读取磁盘也是离散的读。
所以如果访问到数据占据整个表较大一部分时，优化器会选择聚集索引查找数据（全表扫描就是通过扫描聚集索引叶子节点），因为顺序读的速度远远大于离散读

如果使用的是固态硬盘，因为不需要寻道，所以离散读的性能比较好，可以通过 force index() 强制使用某个索引

索引提示

正常情况下SQL优化器会选择合适的索引，但是DBA可以根据经验直接指定索引来完成查询

MRR
Multi-Range Read优化

较少磁盘的随机访问，并将随机访问转化为较为顺序的数据访问，适用于range,ref,eq_ref类型的查询

使数据访问变得较为顺序。在查询辅助索引时，首先根据得到的查询结果，按照主键进行排序，并按照主键排序的顺序进行书签查找

减少缓冲池中页被替换的次数

批量处理对键值的查询操作

工作方式

将查询得到的辅助索引键值存放与一个缓存中，这时缓冲中的数据是根据辅助索引键值对排序的

将缓存中的键值根据RowId进行排序

根据Rowid的排序顺序来访问实际的数据文件

ICP
Index condition pushdown优化

没优化前，当进行索引查询时，首先根据索引来查找记录，再根据where条件来过滤记录，这样会产生大量的记录页加载

ICP会在取出索引的同时，判断是否可以进行where条件的过滤，也就是将where的部分过滤操作放在了存储引擎层。在某些查询下，可以大大减少上层SQL层对记录的索取，从而提高数据库的整体性能

支持range/ref/eq_ref/ref_or_null类型的查询

全文索引

B+索引虽然支持对某列的前缀进行索引，但是对于查找一个博客中包含单词 xxx 的文章是无法满足的

全文检索是将存储于数据库中的整本书或者整篇文章中的任意内容信息查找出来的技术

Innodb从 1.2.x版本开始，已经支持全文检索，还支持了其他特性

全文检索通过倒排索引实现

倒排索引需要将 word 放到一张表中，这张表称为 auxiliary table 辅助表

为了提供检索性能，辅助表可能有多个，没张表根据word 的 latin编码进行分区

引擎根据文档分词将分词结果放入到FTS Index Cache(全文检索索引缓存)中，然后再根据情况刷新到辅助表

在一个辅助表中存储单词与单词自身在一个或多个文档所在位置之间的映射

inverted file idex 其表现为{单词，[单词所在的文档ID数组] }

full inverted index {单词，[(单词所在文档ID,在文档中的位置)]}

Innodb采用 full inverter index 的方式

innodb全文检索的限制

每张表只能有一个全文检索的索引

由多列组合而成的全文检索的索引列必须使用相同的字符集和排序规则

不支持没有单词界定符的语言，如中文、日语、韩语等

哈希索引（自适应哈希索引）

直接寻址
数组大小受限

哈希表、哈希碰撞

将关键字转换为自然数，通过除法散列、乘法散列或者全域散列，数据库一般使用除法散列

链接法

哈希索引只适合等值查询，对于范围查询是失效的

innodb不支持直接设置哈希索引，引擎会根据数据访问情况，自己控制建立哈希索引，称为自适应哈希索引

InnoDB存储引擎

体系架构

InnoDB引擎结构

后台线程

多线程模型，不同的后台线程处理不同的任务

Master Thread

核心线程，负责将缓冲池中的数据异步刷新到磁盘，保证数据的一致性，包括脏页的刷新、合并插入缓冲、Undo页的回收

IO Thread

InnoDB 使用AIO处理IO请求，提高数据库性能，IO Thread负责这些请求的回调

write/read/insert buffer/log io thread

Purge Thread(净化事务)

事务被提交后，其使用的undolog可能不再需要，需要 purge thread来回收已经使用并分配的undo页

Page Cleaner Thread
（页清洁线程）

将之前版本中脏页的刷新操作都放入到单独的线程中来完成

减轻原Master Thrad 的工作及对于用户查询线程的阻塞，进一步提供InnoDB存储引擎的性能

内存

InnoDB是基于磁盘存储的，但磁盘读取速度慢，所以使用缓冲池技术来提高数据库的整体性能

缓冲池

引擎读取数据不是直接读取硬盘，而是通过一块内存区域，通过内存的速度来弥补磁盘速度较慢对数据库性能的影响

读缓存，读取数据页时，先判断该页是否在缓冲区中，如果缓存命中则返回；如果不存在，那么先从磁盘读取该页到缓存池（FIX过程），再返回数据

写缓存，所有的修改操作，都先修改缓存池的值，再通过某种机制刷新到硬盘

checkpoint

缓冲池数据页类型

索引页

数据页

UNDO页

插入缓冲

自适应哈希索引

innodb存储的锁信息

数据字典信息

多缓冲池实例，减少数据库内部竞争，增加数据库的并发能力

innodb_buffer_pool_instances

内存管理，淘汰机制

LRU List、Free List、Flush Fist

Lru

最近最少使用淘汰，最频繁使用的放列表前端，最少使用的放尾端，缓冲池满时先释放尾端的页

mindpoint

新增的页，不是直接放到前端，而是放到 minpoint 的位置上

避免全盘扫描或者某个不常用的数据的偶尔加载，插入到队列前会形成误杀

重做日志缓冲

InnoDB首先将重做日志放入到这个缓冲区，然后按一定的频率将其刷新到重做文件

innodb_log_buffer_size

默认8MB

刷新情况

Master Thread 每一秒将重做日志缓冲刷新到重做日志文件

每个事务提交时会将重做日志缓冲刷新到重做日志文件

当重做日志缓冲池剩余空间小于1/2时

什么是重写日志

服务器意外宕机导致实例失败，Innodb存储引擎利用重做日志恢复到宕机前的状态，以此保证数据的完整性。

额外的内存池

数据结构本身的内存进行分配时，需要从该区域分配

checkpoint

页面操作先在内存缓冲区，再刷新到磁盘，如果刷新磁盘时发生的宕机，那么数据将丢失。为了解决这个文件，当前事务数据库普遍使用 write ahead log策略，即事务提交时，先写重做日志，再修改页。这样即使宕机，也可以通过重做日志来完成数据的恢复。
但是重做日志没有redis的redo功能，对于运行时间较长或者提交较大的重做日志恢复是非常耗时的，所以需要 CheckPoint 解决

当数据库发生宕机时,数据库不需要重做所有的日志,因为Checkpoint之前的页都·已经刷新回磁盘。故数据库只需对Checkpoint后的重做日志进行恢复。

Checkpoint 解决的问题

缩短数据库的恢复时间

数据库只需要到checkpoint后的日志进行恢复

缓冲池不够用时，将脏页刷新到磁盘

重做日志不可用时，刷新脏页

Master Thread 工作方式

早期版本的循环

主循环

每秒一次的操作

日志缓冲刷新的磁盘，即使这个事务未提交（总是）

合并插入缓冲（可能）

至多刷新100个Innodb的缓冲池中的脏页到磁盘(可能)

如果当前没有用户活动，则切换到backgroud loop(可能)

每十秒一次的操作

刷新 100 个脏页到磁盘可能

合并至多5个插入缓冲总是

将日志缓冲刷新到磁盘总是

删除无用的 undo 页总是

full purge 清理无用的行

刷新100 个或者 10个脏页到磁盘总是

10+1 而不是 9+1的操作

后台循环

删除无用的 undo 页总是

合并20个插入缓冲总是

跳回主循环总是

不断刷新 100 个页直到符合条件可能（跳转到 flush loop）

刷新循环

不断刷新 100 个页直到符合条件

跳到 suspend_ loop

暂停循环

没什么事，就挂起来

更新后的循环 1.0.X

随着磁盘IO的提升，硬编码的方式固定主循环的各种数量可能得不到最大的性能

在合并插入缓冲时，合并的数量未innodb_io_capacity值的5%

从缓冲区刷新脏页时，刷新脏页的数量为 innodb_io_capacity

自适应刷新，动态调节每秒刷新脏页的数量

从Master Thread 线程分离出一个单独的 page cleaner thread 用于脏页的刷新操作，提高系统并发性

伪代码

子主题

package com.tsintergy.adss.serviceimpl.algorithm.base; public class 前往 { void masteor_thread(){ loop: //主循环,间隔10s for(int i=0;i thread_sleep(1) //sleep 1 s do log buffer flush to disk //每秒都要刷新日志缓存到硬盘 if(last_one_second_iosinnodb_max_dirty_pages_pct){//如果缓存中的脏页比例大于配置中的innodb_max_dirty_pages_pct就刷新innodb_io_capacity个脏页到硬盘 do buffer pool flush 100% innodb_io_capacity dirty page } if(no user activity){ //如果当前没有活跃用户或者数据库关闭时，就跳入background loop goto backgroud loop } sleep 1 second if necessary } //每10秒执行的操作 if(last_ten_second_ios< innodb_io_capacity){ //如果最后10s内IO小于innodb_io_capacity次，那么就刷新innodb_io_capacity个脏页到硬盘 do buffer pool flush 100% * innodb_io_capacity dirty page } do merge at most 5 insert buffer //总是合并最多5个插入缓存 do log buffer flush to disk //总是将日志缓存刷新到磁盘 do full purge //总是删除buffer_pool中无用的undo页，一次最多20个 if(buf_get_modified_ratio_pct>70%){ //如果缓存中脏页比例大于70%，就刷新innodb_io_capacity个脏页到硬盘，否则只刷新10%*innodb_io_capacity个 do buffer pool flush 100% * innodb_io_capacity dirty page }else{ buffer pool flush 10% * innodb_io_capacity dirty page } do fuzzy checkpoint //产生一个检查点 goto loop: background loop: //backupgroud循环 do full purge //总是删除bufferpool中无用的undo页 do merge 100% * innodb_io_capacity insert buffer //总是合并innodb_io_capacity个插入缓存 if not idle：//如果不空闲，就跳回主循环，如果空闲就跳入flush loop goto loop： else goto flush loop flush loop: do buffer pool flush 100% * innodb_io_capacity dirty page //总是刷新innodb_io_capacity个脏页到硬盘，直到缓存中的脏页比例小于innodb_max_dirty_pages_pct if(buf_get_modified_ratio_pct>innodb_max_dirty_pages_pct){ goto flush loop } goto suspend loop //完成刷新脏页的任务后，跳入suspend loop suspend loop: suspend_thread() //将master线程挂起，等待事件激活 waiting event goto loop: } }

InnoDB的关键特性

插入缓冲 insert buffer

对于主键顺序插入的数据，插入速度很快，因为数据页的存放是按照主键顺序存放的。
但是对于非聚集的且不是唯一的索引，数据的插入不是连续的，所以需要离散的访问非聚集索引页，随机读取的存在会导致插入操作性能下降

mysql 的插入缓冲，在非聚集索引的插入或更新时，不直接插入到索引页，而是先判断插入的非聚集索引页是否在缓冲池中，若在，则直接插入；如果不在，不会去读数据，而是先放入到一个insert buff对象中，然后再以一定的频率和情况进行 insert buffer 和辅助索引页子节点合并操作，这是通常能将多个插入合并到一个操作中，这就大大提高了对于非聚集索引插入的性能

使用插入缓存的条件

索引是辅助索引

索引不是唯一的

因为在插入时，数据库并不去查找插入记录的唯一性，否则就需要离散的读取数据，这使 insert buffer 失去了意义

风险点，如果数据库宕机时还有大量的缓存没合并到实际的索引中去，恢复这些数据可能需要很长的时间

change buffer ，insert buffer的升级，对 insert/delete/update 操作都进行缓存

内部实现

通过全局 insert buffer B+树，记录插入的表，key,insert buffer 顺序，插入记录的各个字段

两次写 double write

提高innodb的数据页可靠性

在引擎写入磁盘时，如写入16K，但是发生了宕机，实际上只写入了4k，就会发生部分写失效，导致数据丢失的情况

部分写失效不能通过重做日志恢复，因为重做日志记录的是对也的物理操作，如偏移量800，写‘aaa’记录，但是以为部分写导致这个也本身损坏了，所以重做也是没有意义的

因此需要有一个也的副本，但是写入失效发生时，先通过也的副本来还原该页，在进行重做，这就是doublewrite

过程

doublewrite 有两部分组成，一部分是内存中的doublewrite buffer，大小为2M，另一部分是物理磁盘上共享表空间中连续的 128页，大小也是2M。
在对脏页进行刷新时，并不直接写磁盘，而是会通过 memcpy 函数将脏页先复制到内存中的 doublewrite buffer，之后分两次每次一1M顺序写入共享表空间的物理硬盘，然后马上调用fsync刷盘。
在完成了共享表空间的写入后，再将doublewrite buffer 中的页写入到真实的表空间文件。

如果写入磁盘的过程发生崩溃，在恢复过程汇总，引擎会先从共享表空间中的doublewrite中找到该页的部分，将其复制到表空间文件，再应用重做日志。

如果是从服务器，可以通过 skip_innodb_doublewrite 关闭 doublewrite来提升性能，但是主服务器必需开启doublewrite功能

自适应哈希索引 adaptive hash index

InnoDB监控对表上索引页的查询，如果观察到建立哈希索引可以带来速度提升，则建立哈希索引，称之为自适应哈希索引AHI

AHI要求对这个页的连续访问模式（查询的条件）必须是一样的

异步IO async io

为了提高磁盘操作性能，当前数据库都采用异步IO，异步IO可以发出一个请求后无需等待立即发起另一个请求，当所有IO请求发送完毕后，等待所有IO操作的完成。

AIO的另一个优势是可以进行IO Merge操作

操作系统的影响（Windows、Linux支持），（Mac OSX不支持）

刷新邻接页 flush neighbor page

当刷新一个脏页时，Innodb存储引擎会检测该页所在区的所有页，如果是脏页，那么一起进行刷新

是否开启innodbflush-neighbors

固态建议关闭

机械建议开启

启动、关闭和恢复

innodb_fast_shutdown参数

0

表示mysql数据库关闭时，innodb需要完成所有的full purge（净化）和 merge insert buffer，并将所有的脏页刷新会磁盘。耗时长

1

默认值，表示不需要完成 full purge 和 merge insert buffer 操作，但是在缓冲池中的一些数据还是会刷新会磁盘

2

表示不完成 full purge 和 merge insert buffer 操作，也不刷新脏页，而是将日志都写入日志。这样不会有任何的事务丢失，但是下次数据库启动时，需要进行恢复操作

innodb_force_recovery

1

(SRV-FORCE IGNORE-CORRUPT)忽略检查到的corrupt页

2

(SRV-FORCE NO-BACKGROUND)阻止Master Thread线程的运行,如MasterThread线程需要进行full purge操作,而这会导致crash

3

(SRVFORCE NO-TRX-UNDO)不进行事务的回滚操作

4

(SRV-FORCENOIBUFMERGE):不进行插入缓冲的合并操作

5

(SRV-FORCE NO-UNDO LOG SCAN):不查看撤销日志(Undo Log), InnoDB存储引擎会将未提交的事务视为已提交

6

SRV FORCENO LOG-REDO):不进行前滚的操作

InnoDB引擎

子主题

表

索引组织表

表都是根据主键顺序组织存放的，这种存储方式的表称为索引组织表

Innodb 逻辑存储结构

所有的数据都被逻辑地存放在一个空间，称之为表空间，表空间由段、区、页组成

表空间

Innodb所有的数据都放在表空间，默认所有数据存在一个共享表空间，可以通过 innodb_file_per_table 将没张表内的数据放入一个单独的表空间

共享表空间

回滚信息、插入缓冲索引页、系统事务信息、二次写缓存等

区

由连续的页组成的空间，大小为1mb

页

最小的磁盘管理单位，默认大小16k，通过 innodb_page_size 设置

分类

数据页

undo页

系统页

事务数据页

插入缓冲位图页

插入缓冲空闲列表页

未压缩的二进制大对象页

压缩的二进制大对象页

存储结构

file header 文件头

page header 页头

infimun / Supremum records

user records 用户空间，即行记录

free spack 空闲空间

page directory 页目录

file trailer 文件结尾信息

行

innodb是面向列的，所以数据是按行进行存放的，每个页最多允许存放 16KB/ 2~200行的记录

一个数据行最多支持1024列，就是一个表最多有1024个字段

行记录格式

Compact

一个页存放的行数据越多，性能越高

Null 值除了占用标记位，实际存储不占有任何空间

Redundant

compressed/dynamic

zlib算法压缩

mysql 中对varchar 的最大长度是65532，但是因为需要保留字段记录当前 varchar 的实际长度是多少需要占用两个字节，所以实际上是不能存满的

varchar 最长长度 65532不是针对单个字段，而是一个表字段的所有总和

一个页是 16K，最多存储16384字节，所以对于超长的varhcar 字段，当发生行溢出时，数据放在页类型为uncompress blob页中

约束

约束是为了保证数据完整性

Enum 和 set 约束

触发器约束

外键约束

视图

虚表，由一个SQL查询来定义，可以当做表使用，视图中的数据没有实际的物理存储

根据情况可以对视图进行更新，实际是更新到真实的表中

表分区

分区的过程是将一个表或者索引分解为多个更小、更可管理的部分。从逻辑上讲只有一个表，但是在物理上可能由数十个物理分区组成，每个分区都是独立的对象，可以独自处理，也可以作为一个更大对象的一部分进行处理

例如可以对每个分区做单独的统计，也可以把各个去的统计再合并作为总表统计

mysql 是水平分区，分区方式是局部分区索引，一个分区中即存放了数据又存放了索引

对应的全局分区是数据放在各个分区，但是所有数据的索引放在一个对象中

MYSQL根据分区列应用下面的分区类型实现分区，如果表中存在主键或者唯一索引，那么分区列必须是其中的一个组成部分；如果未指定主键或者唯一索引，那么可以指定任何一个列为分区列；包含NULL值的列也可以

分区修建/partition pruning
当查询条件满足分区数据要求时，sql只会搜索指定的分区，而不会搜索所有分区

mysql分区中，对 null 值的处理是总是视为任何一个小于非null值

分区类型

Range分区
行数据基于属于一个给定连续区间的列值被放入分区

主要用于区分日期列的分区

Create table sales(
date datetime
money int
) engine = innodb
partiton by range (to_days(date))(
partition p202001 values less then(to_days('2020-02-01')),
partition p202002 values less then(to_days('2020-03-01'))
)

List分区
和Range分区类似，只是List分区面向的是离散的值

与range分区相似，但是分区列的值是离散的

create table
t(a int)
engine = innodb
partition by list(a)(
partition p0 by values in (1,2,3,4),
partition p1 by values in (5,6,7,8)
)

HASH分区
根据用户自定义的表达式的返回值来进行分区

将数据均匀的分布到预先定义的各个分区中，不需要像range/list指定分区列的集合或范围
用户将要进行哈希分区的列值指定一个列值或者表达式，以及指定被分区的表将要被分隔成的分区数量

哈希分区中， partition不需要指定分区名，但是 partition {num} 表示分区的数量

create table t_hash(
a int
b datetime
)engine = innodb
partition by hash (year(b))
partition 4;

KEY分区
根据Mysql数据库提供的哈希函数来进行分区

与HASH分区相似，但是不需要用户指定hash 函数，而是使用mysql提供的函数分区

create table t_key(
a int
b datetime
) engine = innodb
partition by key(b)
partition 4;

Columns分区

前面四种的分区的条件是：数据必须是整数，如果不是整数，必须通过函数将其转化为整数。

从MYSQL5.5版本开支持 columns 分区，可以直接使用非整形的数据进行分区，分区根据类型直接比较而得。

子分区

在分区的基础上在进行分区，也称为复合分区；运行在 range 和 list 分区基础上再进行 hash key 分区

每个子分区的数量必须相同

要在一个分区表的任何分区上使用subpartition来明确定义任何子分区，就必须定义所有的子分区

每个子分区必须有一个唯一的名字

可以通过 data directory = '/disk0/data' 来将一个表的分区文件分配到多个磁盘中，可以提升性能

create table ts (a int ,b date)
partition by range (year(b))
subpartition by hash(to_days(b))(
partiotion p0 values less than(1990)(
subpartition s0,
subpartition s1
),
partition p1 values less than maxvalues(
subpartition s2,
subpartition s3
)
)

分区和性能

OLAP适合分区，因为在线分区一般都会处理一段维度内的数据

对于OLTP则需要根据实际情况处理，因为在线事务查询条件比较复杂，如果需要跨多个分区查找数据，会需要更多的IO

文件

参数文件

show variables like '% %'

日志文件

错误日志

对启动、运行、关闭过程进行处理

慢查询日志/slow log

记录运行时间超过阈值的所有SQL

long_query_time，默认10

mysqldumpslow

查询日志

记录所有对mysql数据库的请求信息，无论这些请求是否得到正确的执行

二进制日志

记录对数据库执行更改的操作，但是不包括select 和 show 这类操作

二进制日志会先写到buffer中，如果缓冲溢出大小，mysql会吧缓冲中的日志写入一个临时文件中

binlog_format 参数

statement

记录逻辑SQL语句

row

记录表的行的更改情况

mixed

默认采用 statement，但是会根据实际情况调整

作用

恢复

复制，通过复制二进制日志文件是一台远程的从数据库和一个 master 服务器进行实时同步

审计

通过二进制日志中的信息来进行审计，判断是否有对数据库进行注入攻击

socket文件

本地连接mysql可以采用 unix 域套接字方式，这种方式需要一个套接字文件

pid文件

记录进程ID的文件

mysql 表结构文件

表结构定义，视图定义

存储引擎文件

表空间文件

重做日志文件

与二进制日志的区别是，二进制文件记录所有的有关日志记录，包括innodb、myisam、heap 等，而innodb存储引擎的重做日志只记录有关改引擎本身的事务日志

Mysql体系结构和存储引擎

定义数据库和实例

数据库

物理操作系统文件、内存数据或者其他形式文件类型的集合，在mysql下数据库文件可以是frm，myd，myi，ibd结尾的文件

实例

Mysql数据库由后台线程以及一个内存共享区组成

Mysql 体系结构

连接池组件

管理服务和工具组件

SQL接口组件

查询分析器组件

优化器组件

缓冲（Cache）组件

插件式存储引擎

物理文件

子主题

mysql存储引擎

Innodb

支持事务，设计目标主要面向在线事务处理（OLTP）的应用

行锁设计、支持外键，默认读取操作不会产生锁。mysql 5.5.8版本开始的默认存储引擎

通过多版本并发控制（MVCC）来获得高并发，并实现了SQL标准的4种隔离级别。

使用next-keylocking的策略来避免幻读

提供插入缓冲、二次写、自适应哈希索引、预读等高性能和高可用的功能

才用聚集的方式，每张表的存储都是按主键顺序存放，如果没有显示指定主键，Innodb会为每一行生成一个6字节的rowid为主键

MyISAM

不支持事务、表锁设计，支持全文索引。

缓冲池只缓存索引文件，而不索引数据文件

由MYD和MYI组成，MYD用来存放数据文件，MYI用来存放索引文件