MySQL体系结构和存储引擎概述

1、定义数据库和实例

 

在数据库领域中有两个词很容易混淆，它们就是“实例”（instance）和“数据库”（database）。作为常见的数据库术语，这两个词的定义如下。

从定义上区分，

❑数据库：物理操作系统文件或其他形式文件类型的集合。在MySQL中，数据库文件可以是frm、myd、myi、ibd结尾的文件。当使用NDB引擎时，数据库的文件可能不是操作系统上的文件，而是存放于内存之中的文件，但是定义仍然不变。

❑数据库实例：由数据库后台进程/线程以及一个共享内存区组成。共享内存可以被运行的后台进程/线程所共享。需要牢记的是，数据库实例才是真正用来操作数据库文件的。

这两个词有时可以互换使用，但两者的概念完全不同。在MySQL中，实例和数据库的通常关系是一一对应，即一个实例对应一个数据库，一个数据库对应一个实例。但是，在集群情况下可能存在一个数据库可被多个实例使用的情况。

 

从概念上来说，

❑数据库是文件的集合，是依照某种数据模型组织起来并存放于二级存储器中的数据集合；❑数据库实例是应用程序，是位于用户与操作系统之间的一层数据管理软件，用户对数据库数据的任何操作，包括数据库定义、数据查询、数据维护、数据库运行控制等，都是在数据库实例下进行的，应用程序只有通过数据库实例才能和数据库打交道。

 

一种更直白的方式来解释：

数据库是由一个个文件组成（一般来说都是二进制的文件）的，如果要对这些文件执行诸如SELECT、INSERT、UPDATE和DETELE之类的操作，不能通过简单的操作文件来更改数据库的内容，需要通过数据库实例来完成对数据库的操作。所以，如果你把Oracle、SQL Server、MySQL简单地理解成数据库，可能是有失偏颇的，虽然在实际使用中我们并不会这么强调两者之间的区别。

 

2、配置查看

 

MySQL被设计为一个单进程多线程架构的数据库，这点与SQL Server比较类似，但与Oracle多进程的架构有所不同（Oracle的Windows版本也是单进程多线程的架构）

用以下命令可以查看，当MySQL数据库实例启动时，它会在哪些位置查找配置文件。

 

[root@xen-server bin]# ./mysql --help | grep my.cnf

order of preference, my.cnf, $MYSQL_TCP_PORT,

/etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf

 

可以看到，MySQL是按/etc/my.cnf→/etc/mysql/my.cnf→/usr/local/mysql/etc/my.cnf→~/.my.cnf的顺序读取配置文件的。可能有人会问：“如果几个配置文件中都有同一个参数， MySQL以哪个配置文件为准？”答案很简单，MySQL会以读取到的最后一个配置文件中的参数为准。在Linux环境下，配置文件一般放在/etc/my.cnf下。在Windows平台下，配置文件的后缀名可以是.cnf，也可能是.ini。运行mysql -help命令，可以找到以下的内容：

 

Default options are read from the following files in the given order:

C:\Windows\my.ini C:\Windows\my.cnf C:\my.ini C:\my.cnf

C:\Program Files\MySQL\M\MySQL Server 5.1\my.cnf

 

配置文件中有一个datadir参数，该参数指定了数据库所在的路径。在Linux操作系统下， datadir默认为/usr/local/mysql/data。

 

3、Mysql体系结构

 

三个问题：

❑为什么MySQL不支持全文索引？

❑MySQL速度快是因为它不支持事务？

❑数据量大于1 000W时，MySQL的性能会急剧下降吗？

 

MySQL体系结构图：

(待补充)

 

 

从图中我们可以发现，MySQL由以下几部分组成：

❑连接池组件。

❑管理服务和工具组件。

❑SQL接口组件。

❑查询分析器组件。

❑优化器组件。

❑缓冲（Cache）组件。

❑插件式存储引擎。

❑物理文件。

从图中还可以看出，MySQL区别于其他数据库的最重要的特点就是其插件式的表存储引擎。

 

4、存储引擎

 

4.1、 InnoDB存储引擎

 

InnoDB存储引擎支持事务，主要面向在线事务处理（OLTP）方面的应用。其特点是行锁设计、支持外键，并支持类似于Oracle的非锁定读，即默认情况下读取操作不会产生锁。MySQL在Windows版本下的InnoDB是默认的存储引擎，同时InnoDB默认地被包含在所有的MySQL二进制发布版本中。

InnoDB存储引擎将数据放在一个逻辑的表空间中，这个表空间就像黑盒一样由InnoDB自身进行管理。从MySQL 4.1（包括4.1）版本开始，它可以将每个InnoDB存储引擎的表单独存放到一个独立的ibd文件中。与Oracle类似，InnoDB存储引擎同样可以使用裸设备（row disk）来建立其表空间。

InnoDB通过使用多版本并发控制（MVCC）来获得高并发性，并且实现了SQL标准的4种隔离级别，默认为REPEATABLE级别。同时使用一种被称为next-key locking的策略来避免幻读（phantom）现象的产生。除此之外，InnoDB储存引擎还提供了插入缓冲（insert buffer）、二次写（double write）、自适应哈希索引（adaptive hash index）、预读（read ahead）等高性能和高可用的功能。

对于表中数据的存储，InnoDB存储引擎采用了聚集（clustered）的方式，这种方式类似于Oracle的索引聚集表（index organized table，IOT）。每张表的存储都按主键的顺序存放，如果没有显式地在表定义时指定主键，InnoDB存储引擎会为每一行生成一个6字节的ROWID，并以此作为主键。

 

4.2、MyISAM存储引擎

 

MyISAM存储引擎是MySQL官方提供的存储引擎。其特点是不支持事务、表锁和全文索引，对于一些OLAP（Online Analytical Processing，在线分析处理）操作速度快。除Windows版本外，是所有MySQL版本默认的存储引擎。

MyISAM存储引擎表由MYD和MYI组成，MYD用来存放数据文件，MYI用来存放索引文件。可以通过使用myisampack工具来进一步压缩数据文件，因为myisampack工具使用赫夫曼（Huffman）编码静态算法来压缩数据，因此使用myisampack工具压缩后的表是只读的，当然你也可以通过myisampack来解压数据文件。

在MySQL 5.0版本之前，MyISAM默认支持的表大小为4G，如果需要支持大于4G的MyISAM表时，则需要制定MAX_ROWS和AVG_ROW_LENGTH属性。从MySQL 5.0版本开始，MyISAM默认支持256T的单表数据，这足够满足一般应用的需求。

注意：对于MyISAM存储引擎表，MySQL数据库只缓存其索引文件，数据文件的缓存交由操作系统本身来完成，这与其他使用LRU算法缓存数据的大部分数据库大不相同。

 

4.3、其他存储引擎

 

其他存储引擎包括：

NDB Memory Archive Federated Maria Merge CSV Sphinx Infobright 等存储引擎。

下图(不同MySQL存储引擎相关特性的比较)取自于MySQL的官方手册，展现了一些常用MySQL存储引擎之间的不同之处，包括存储容量的限制、事务支持、锁的粒度、MVCC支持、支持的索引、备份和复制等。

(待补充)

 

 

 

4.4、问题解答

 

❑ 为什么MySQL不支持全文索引？不！MySQL支持，MyISAM、Sphinx存储引擎支持全文索引。

❑MySQL快是因为不支持事务吗？错！MySQL MyISAM存储引擎不支持事务，但是InnoDB支持。快是相对于不同应用来说的，对于ETL这种操作，MyISAM当然有其优势。

❑当表的数据量大于1 000W时，MySQL的性能会急剧下降吗？不！MySQL是数据库，不是文件，随着数据行数的增加，性能当然会有所下降，但是这些下降不是线性的，如果你选择了正确的存储引擎以及正确的配置，再大的数据量MySQL也是能承受的。如官方手册上提及的，Mytrix和Inc.在InnoDB上存储了超过1TB的数据，还有一些其他网站使用InnoDB存储引擎处理平均每秒800次插入/更新的操作。

 

附：

 

1、MyISAM和InnoDB比较(来自百度问答)

 

MyISAM:这个是默认类型,它是基于传统的ISAM类型,ISAM是Indexed Sequential Access Method (有索引的 顺序访问方法) 的缩写,它是存储记录和文件的标准方法.与其他存储引擎比较,MyISAM具有检查和修复表格的大多数工具. MyISAM表格可以被压缩,而且它们支持全文搜索.它们不是事务安全的,而且也不支持外键。如果事物回滚将造成不完全回滚，不具有原子性。如果执行大量 的SELECT，MyISAM是更好的选择。

InnoDB:这种类型是事务安全的.它与BDB类型具有相同的特性,它们还支持外键.InnoDB表格速度很快.具有比BDB还丰富的特性,因此如果需要一个事务安全的存储引擎,建议使用它.如果你的数据执行大量的INSERT或UPDATE,出于性能方面的考虑，应该使用InnoDB表, 对于支持事物的InnoDB类型的表，影响速度的主要原因是AUTOCOMMIT默认设置是打开的，而且程序没有显式调用BEGIN 开始事务，导致每插入一条都自动Commit，严重影响了速度。可以在执行sql前调用begin，多条sql形成一个事物（即使autocommit打 开也可以），将大大提高性能

 

2、全文索引(来自百度百科)

 

全文索引技术是目前搜索引擎的关键技术。

试想在1M大小的文件中搜索一个词，可能需要几秒，在100M的文件中可能需要几十秒，如果在更大的文件中搜索那么就需要更大的系统开销，这样的开销是不现实的。

所以在这样的矛盾下出现了全文索引技术，有时候有人叫倒排文档技术。

 

原理

原理是先定义一个词库，然后在文章中查找每个词条(term)出现的频率和位置，把这样的频率和位置信息按照词库的顺序归纳，这样就相当于对文件建立了一个以词库为目录的索引，这样查找某个词的时候就能很快的定位到该词出现的位置。

 

问题

在处理英文文档的时候显然这样的方式是非常好的，因为英文自然的被空格分成若干词，只要我们有足够大的词汇库就能很好的处理。但是亚洲文字因为没有空格作为断词标志，所以就很难判断一个词，而且人们使用的词汇在不断的变化，而维护一个可扩展的词汇库的成本是很高的，所以问题出现了。

 

解决

解决出现这样的问题使“分词”成为全文索引的关键技术。目前有两种基本的方法：

二元法 它把所有有可能的每两两汉字的组合看为一个词组，这样就没有维护词库的开销。

词库法 它使使用词库中的词作为切分的标准，这样也出现了词库跟不上词汇发展的问题，除非你维护词库。

实际上现在很多著名的搜索引擎都使用了多种分词的办法，比如“正向最大匹配”+“逆向最大匹配”，基于统计学的新词识别，自动维护词库等技术，但是显然这样的技术还没有做到完美。

 

参考书籍：
《MySQL技术内幕InnoDB存储引擎》