MySQL数据库的体系架构如下图所示：
从上图中可以看出，MySQL主要分为以下几个组件：
- 连接池组件
- 管理服务和工具组件
- SQL接口组件
- 分析器组件
- 优化器组件
- 缓冲组件
- 插件式存储引擎
- 物理文件
下表显示了各种存储引擎的特性：
其中最常见的两种存储引擎是MyISAM和InnoDB
刚接触MySQL的时候可能会有些惊讶，竟然有不支持事务的存储引擎，学过关系型数据库理论的人都知道，事务是关系型数据库的核心。但是在现实应用中（特别是互联网），为了提高性能，在某些场景下可以摈弃事务。下面一一介绍各种存储引擎：
MyISAM存储引擎
InnoDB存储引擎
InnoDB存储引擎支持事务，主要面向OLTP方面的应用，其特点是行锁设置、支持外键，并支持类似于Oracle的非锁定读，即默认情况下读不产生锁。InnoDB将数据放在一个逻辑表空间中（类似Oracle）。InnoDB通过多版本并发控制来获得高并发性，实现了ANSI标准的4种隔离级别，默认为Repeatable，使用一种被称为next-key locking的策略避免幻读。
对于表中数据的存储，InnoDB采用类似Oracle索引组织表Clustered的方式进行存储。
InnoDB 存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比Myisam的存储引擎，InnoDB 写的处理效率差一些并且会占用更多的磁盘空间以保留数据和索
引。
NDB存储引擎
NDB存储引擎是一个集群存储引擎，类似于Oracle的RAC，但它是Share Nothing的架构，因此能提供更高级别的高可用性和可扩展性。NDB的特点是数据全部放在内存中，因此通过主键查找非常快。
关于NDB，有一个问题需要注意，它的连接(join)操作是在MySQL数据库层完成，不是在存储引擎层完成，这意味着，复杂的join操作需要巨大的网络开销，查询速度会很慢。
Memory (Heap) 存储引擎
Memory存储引擎（之前称为Heap）将表中数据存放在内存中，如果数据库重启或崩溃，数据丢失，因此它非常适合存储临时数据。
Archive存储引擎
正如其名称所示，Archive非常适合存储归档数据，如日志信息。它只支持INSERT和SELECT操作，其设计的主要目的是提供高速的插入和压缩功能。
Federated存储引擎
Federated存储引擎不存放数据，它至少指向一台远程MySQL数据库服务器上的表，非常类似于Oracle的透明网关。
Maria存储引擎
Maria存储引擎是新开发的引擎，其设计目标是用来取代原有的MyISAM存储引擎，从而成为MySQL默认的存储引擎。
InnoDB是事务安全的存储引擎，设计上借鉴了很多Oracle的架构思想，一般而言，在OLTP应用中，InnoDB应该作为核心应用表的首先存储引擎。InnoDB是由第三方的Innobase Oy公司开发，现已被Oracle收购，创始人是Heikki Tuuri，芬兰赫尔辛基人，和著名的Linux创始人Linus是校友。
InnoDB体系架构
后台线程
内存
Master 后台线程
- void master_thread() (
- loop:
- for (int i =0; i <10; i++){
- do thing once per second
- sleep 1 second if necessary
- }
- do things once per ten seconds
- goto loop;
- }
- 刷新日志缓冲区（总是）
- 合并插入缓冲（可能）
- 至多刷新100个脏数据页（可能）
- 如果没有当前用户活动，切换至background loop （可能）
- 合并至多5个插入缓冲（总是）
- 刷新日志缓冲（总是）
- 刷新100个或10个脏页到磁盘（总是）
- 产生一个检查点（总是）
- 删除无用Undo 页 （总是）
- 删除无用的undo页（总是）
- 合并20个插入缓冲（总是）
- 跳回到主循环（总是）
- 不断刷新100个页，直到符合条件跳转到flush loop（可能）
在上一篇《》中，我们可以看到在InnoDB的内存中有单独一块叫“插入缓冲”的区域，下面我们详细来介绍它。
非聚集索引写性能问题
为了阐述非聚集索引写性能问题，我们先来看一个例子：
mysql>create table t ( id int auto_increment, name varchar(30), primary key (id)); 我们创建了一个表，表的主键是id，id列式自增长的，即当执行插入操作时，id列会自动增长，页中行记录按id顺序存放，不需要随机读取其它页的数据。因此，在这样的情况下（即聚集索引），插入操作效率很高。
但是，在大部分应用中，很少出现表中只有一个聚集索引的情况，更多情况下，表上会有多个非聚集的secondary index （辅助索引）。比如，对于上一张表t，业务上还需要按非唯一的name字段查找，则表定义改为：
mysql>create table t ( id int auto_increment, name varchar(30), primary key (id), key (name)); 这时，除了主键聚合索引外，还产生了一个name列的辅助索引，对于该非聚集索引来说，叶子节点的插入不再有序，这时就需要离散访问非聚集索引页，插入性能变低。
插入缓冲技术机制
为了解决这个问题，InnoDB设计出了插入缓冲技术，对于非聚集类索引的插入和更新操作，不是每一次都直接插入到索引页中，而是先插入到内存中。具体做法是：如果该索引页在缓冲池中，直接插入；否则，先将其放入插入缓冲区中，再以一定的频率和索引页合并，这时，就可以将同一个索引页中的多个插入合并到一个IO操作中，大大提高写性能。回忆一下在《 》中提到的master thread主循环其中的一项工作就是每秒中合并插入缓冲（可能）。这个设计思路和HBase中的LSM树有相似之处，都是通过先在内存中修改，到达一定量后，再和磁盘中的数据合并，目的都是为了提高写性能，具体可参考《》，这又再一次说明，学到最后，技术都是相通的。
插入缓冲的启用需要满足一下两个条件： 1）索引是辅助索引（secondary index） 2）索引不适合唯一的 如果辅助索引是唯一的，就不能使用该技术，原因很简单，因为如果这样做，整个索引数据被切分为2部分，无法保证唯一性。
插入缓冲带来的问题
任何一项技术在带来好处的同时，必然也带来坏处。插入缓冲主要带来如下两个坏处： 1）可能导致数据库宕机后实例恢复时间变长。如果应用程序执行大量的插入和更新操作，且涉及非唯一的聚集索引，一旦出现宕机，这时就有大量内存中的插入缓冲区数据没有合并至索引页中，导致实例恢复时间会很长。 2）在写密集的情况下，插入缓冲会占用过多的缓冲池内存，默认情况下最大可以占用1/2，这在实际应用中会带来一定的问题。
今天我们来介绍InnoDB存储引擎的第二个特性 - 两次写（doublewrite），如果说插入缓冲是为了提高写性能的话，那么两次写是为了提高可靠性，牺牲了一点点写性能。
部分写失效
两次写机制
哈希索引是一种非常快的等值查找方法（注意：必须是等值，哈希索引对非等值查找方法无能为力），它查找的时间复杂度为常量，InnoDB采用自适用哈希索引技术，它会实时监控表上索引的使用情况，如果认为建立哈希索引可以提高查询效率，则自动在内存中的“自适应哈希索引缓冲区”（详见《》中内存构造）建立哈希索引。
之所以该技术称为“自适应”是因为完全由InnoDB自己决定，不需要DBA人为干预。它是通过缓冲池中的B+树构造而来，且不需要对整个表建立哈希索引，因此它的数据非常快。
InnoDB官方文档显示，启用自适应哈希索引后，读和写性能可以提高2倍，对于辅助索引的连接操作，性能可以提高5被，因此默认情况下为开启，我们可以通过参数innodb_adaptive_hash_index来禁用此特性。
错误日志
查询日志
慢查询日志
慢查询日志用于记录运行时间比较长的SQL语句，可以通过参数long_query_time来设置该阀值。默认情况下，MySQL并不启动慢查询日志，可以通过设置log_slow_queries为ON启动它。
另一个和慢查询日志相关的参数是log_queries_not_using_indexes，该参数为ON表示如果运行的SQL语句没有使用索引，就将其记录到慢查询日志中。
慢查询日志主要用于协助DBA进行SQL语句的优化。
二进制日志
二进制日志记录了所有数据库的更改操作（SELECT和SHOW不包含在里面），二进制文件在默认情况下没有启动，需要手动指定参数启动。
二进制日志主要有以下两个作用：
1）恢复（recovery）：当一个数据库从全备文件恢复后，我们可以通过二进制日志进行point-in-time恢复。
2）复制（replication）：可以利用它实行从数据库的实时同步。
开启二进制文件会影响性能（根据官方文档显示，开启二进制文件使得数据库性能下降1%左右），但考虑到它带来的好处，这些性能损失还是可以接受的。
MySQL一个显著的特点是其可插拔的存储引擎，因此MySQL文件分为两种，一种是和MySQL数据库本身相关的文件，一种是和存储引擎相关的文件。本文主要介绍和InnoDB存储引擎相关的文件。
表空间文件
重做日志文件
InnoDB存储引擎中的表非常像Oracle中的索引组织表，每张表必须得有主键，如果表在创建时没有显示定义主键，则根据以下原则自动创建主键：
1）如果有非空的唯一索引，则该索引所在的列为主键；
2）如果不符合上述条件，自动创建一个6个字节的指针为主键。
InnoDB存储引擎的逻辑存储结构和Oracle几乎一样，从大到小分别为：表空间、段、区、页，它们的关系如下图所示：
表空间
在上一篇《》中，我们知道InnoDB有一个默认的表空间，如果我们启用了参数innodb_file_per_table，则针对每张可以单独放在表空间里。这里需要注意的是，即时启用了innodb_file_per_table，也并不是表中所有的数据都单独放在自己的表空间里，单独表空间只存放数据、索引和插入缓冲，其它如Undo、系统事务信息、二次写缓冲等还是存放在默认共享表空间里。
段
表空间有若干各段组成，常见的有数据段、索引段、回滚段等。前面提到InnoDB中的表是索引组织表，因此数据段也称为leaf node segment，索引段也称为non-leaf node segment。
区
每64个连续的页组成区，因此区大小正好为1M。
页
页是InnoDB磁盘管理的最小单位，固定大小为16K，不可以更改（也许通过更改源码可以修改固定大小）。
行
InnoDB和大多数行式数据库一样，记录以行的格式存储，它提供了两种格式：Compact和Redundant
Compact
Redundant
Compressed和Dynamic
在实际工作中，常听到初学者说：“大表分区肯定可以提高查询性能”。其实不然，在你完全不了解应用的情况下，盲目的建立分区不但不能够提高查询性能，还有可能导致查询性能下降。因此，在决定是否使用分区之前，必须了解当前的应用环境。
大体上来说，数据库的应用分为两种：OLTP和OLAP。OLTP是指在线事务处理，比如淘宝的购物网站等；OLAP是指在线分析系统，如数据仓库、数据集市等。实际应用中，也有可能出现同一个数据库系统即用于OLTP，也用于OLAP。
对于OLAP应用来说，分区确实能够有效地提高查询性能，因为OLAP通常需要扫描大量的数据（执行计划为全表扫描），分区可以有效地减少扫描的数据量（即分区剪枝 partition elimination）。举个例子，假设有张大表存放了5年的数据，你的应用只需要其中1个月的数据，在没分区之前，需要扫描所有5年的数据，但有了分区之后（假设以时间戳为分区键），只需要扫描1个月的数据即可。而且对于OLAP应用来说，分区还有一个好处就是易于管理，如果你需要对历史数据进行迁移，有分区就非常方便。
但对于OLTP应用来说，分区要非常小心。因为OLTP通常指需要获得很小的一部分数据，通过索引访问是最高效的。根据B+树的原理可知，即使表再大，B+树的高度一般也就是2~3层，因此索引的查询性能不会随着数据量的增大而下降很多。假设分区了，通过分区键索引确实有可能减少IO次数，但如果通过非分区键索引查询呢？试想一下，如果把一张大表分为100个分区，则所以通过非分区键的索引每次都需要在100个分区里查找，性能将会急剧下降！
因此，对于分区是否能够提高查询性能的问题，一定要根据具体的应用决定。切不可盲目分区！
B+树是一种经典的数据结构，由平衡树和二叉查找树结合产生，它是为磁盘或其它直接存取辅助设备而设计的一种平衡查找树，在B+树中，所有的记录节点都是按键值大小顺序存放在同一层的叶节点中，叶节点间用指针相连，构成双向循环链表，非叶节点（根节点、枝节点）只存放键值，不存放实际数据。下面看一个2层B+树的例子：
保持树平衡主要是为了提高查询性能，但为了维护树的平衡，成本也是巨大的，当有数据插入或删除时，需采用拆分节点、左旋、右旋等方法。B+树因为其高扇出性，所以具有高平衡性，通常其高度都在2~3层，查询时可以有效减少IO次数。B+树索引可以分为聚集索引(clustered index)和非聚集索引（即辅助索引，secondary index）。
聚集索引
InnoDB表时索引组织表，即表中数据按主键B+树存放，叶子节点直接存放数据，每张表只能有一个聚集索引。
辅助索引
索引组织表 VS 堆表
复合索引
- alter table t add key idx_a_b(a,b);
