游戏网站交换友情链接,合肥,常德尚一网,腾讯街景地图实景下载2.1 MySQL存储引擎概述
上个业余的图#xff1a;
MyISAM 存储引擎是 MySQL 默认的存储引擎#xff0c;也是目前 MySQL 使用最为广泛的存储引擎之一。他的前身就是我们在 MySQL 发展历程中所提到的 ISAM#xff0c;是 ISAM 的升级版本。在 MySQL最开始发行的时候是 ISAM 存…
2.1 MySQL存储引擎概述
上个业余的图
MyISAM 存储引擎是 MySQL 默认的存储引擎也是目前 MySQL 使用最为广泛的存储引擎之一。他的前身就是我们在 MySQL 发展历程中所提到的 ISAM是 ISAM 的升级版本。在 MySQL最开始发行的时候是 ISAM 存储引擎而且实际上在最初的时候MySQL 甚至是没有存储引擎这个概念的。MySQL在架构上面也没有像现在这样的sql layer和storage engine layer这两个结构清晰的层次结构当时不管是代码本身还是系统架构对于开发者来说都很痛苦的一件事情。 5.1 之前的 版本中虽然存储引擎层和 sql层的耦合已经非常少了基本上完全是通过接口来实现交互但是这两层之间仍然是没办法分离的即使在安装的时候也是一样。
MySQL5.1 开始MySQL AB 对其结构体系做了较大的改造并引入了一个新的概念插件式存储引擎体系结构。MySQL AB 在架构改造的时候让存储引擎层和 sql 层各自更为独立耦合更小甚至可以做到在线加载信的存储引擎也就是完全可以将一个新的存储引擎加载到一个正在 运行的 MySQL 中而不影响 MySQL 的正常运行。插件式存储引擎的架构为存储引擎的加载和移出更为灵活方便也使自行开发存储引擎更为方便简单。在 这 一点上面目前还没有哪个数据库管理系统能够做到。MySQL 的插件式存储引擎主要包括 MyISAMInnodbNDB ClusterMariaFalconMemoryArchiveMergeFederated 等**其中最著名而且使用最为广泛的 MyISAM 和 Innodb两种存储引擎。**MyISAM 是 MySQL 最早的 ISAM 存储引擎的升级版本也是 MySQL 默认的存储 引擎。而 Innodb 实 际上并不是 MySQ 公司的而是第三方软件公司 Innobase在 2005 年被 Oracle 公司所收购所开发其最大的特点是提供了事务控制等特性 所以使用者也非常广泛。
2.2 MySQL存储引擎介绍 MyISAM 存储引擎简介
MyISAM 存储引擎的表在数据库中每一个表都被存放为三个以表名命名的物理文件。首先肯定会有任何存储引擎都不可缺少的存放表结构定义信息的.frm 文件另外还有.MYD和.MYI 文件分别存放了表的数据.MYD和索引数据.MYI。每个表都有且仅有这样三个文件做为 MyISAM 存储类型的表的存储也就是说不管这个表有多少个索引都是存放在同一个.MYI 文件中。
MyISAM 支持以下三种类型的索引
1、B-Tree 索引
B-Tree 索引顾名思义就是所有的索引节点都按照 balance tree 的数据结构来存储所有的索引数据节点都在叶节点。
2、R-Tree 索引
R-Tree 索引的存储方式和 b-tree 索引有一些区别主要设计用于为存储空间和多维数据的字段做索引所以目前的 MySQL 版本来说也仅支持 geometry 类型的字段作索引。
3、Full-text 索引
Full-text 索引就是我们长说的全文索引他的存储结构也是 b-tree。主要是为了解决在我们需要用 like 查询的低效问题。 MyISAM 上面三种索引类型中最经常使用的就是 B-Tree 索引了偶尔会使用到 Fulltext但是 R-Tree 索引一般系统中都是很少用到的。另外 MyISAM 的 B-Tree 索引有一个较大的限制那就是参与一个索引的所有字段的长度之和不能超过 1000 字节。
虽然每一个 MyISAM 的表都是存放在一个相同后缀名的.MYD 文件中但是每个文件的存放格式实际上可能并不是完全一样的因为 MyISAM 的数据存放格式是分为静态FIXED固定长度、动态DYNAMIC可变长度以及压缩COMPRESSED这三种格式。当然三种格式中是否压缩是完全可以任由我们自己选择的可以在创建表的时候通过 ROW_FORMAT 来指定{COMPRESSED | DEFAULT}也可以通过 myisampack 工具来进行压缩默认是不压缩的。而在非压缩的情况下是静态还是动态就和我们表中个字段的定义相关了。只要表中有可变长度类型的字段存在那么该表就肯定是 DYNAMIC 格式的如果没有任何可变长度的字段则为 FIXED 格式当然你也可以通过 alter table 命令强行将一个带有 VARCHAR 类型字段的 DYNAMIC 的表转换为 FIXED但是所带来的结果是原 VARCHAR 字段类型会被自动转换成CHAR 类型。相反如果将 FIXED 转换为 DYNAMIC也会将 CHAR 类型字段转换为 VARCHAR 类型 所以大家手工强行转换的操作一定要谨慎。
MyISAM 存储引擎的表是否足够可靠呢在 MySQL 用户参考手册中列出在遇到如下情况的时候可能会出现表文件损坏
1、当 mysqld 正在做写操作的时候被 kill 掉或者其他情况造成异常终止
2、主机 Crash
3、磁盘硬件故障
4、MyISAM 存储引擎中的 bug
MyISAM 存储引擎的某个表文件出错之后仅影响到该表而不会影响到其他表更不会影响到其他的数据库。如果我们的出据苦正在运行过程中发现某个 MyISAM 表出现问题了则可以在线通过 check table 命令来尝试校验他并可以通过 repair table 命令来尝试修复。在数据库关闭状态下我们也可以通过 myisamchk 工具来对数据库中某个或某些表进行检测或者修复。不过强烈建议不到万不得已不要轻易对表进行修复操作修复之前尽量做好可能的备份工作以免带来不必要的后果。另外 MyISAM 存储引擎的表理论上是可以被多个数据库实例同时使用同时操作的但是不论是我们都不建议这样做而且 MySQL 官方的用户手册中也有提到建议尽量不要在多个mysqld 之间共享 MyISAM 存储文件。
Innodb 存储引擎简介
在 MySQL 中使用最为广泛的除了 MyISAM 之外就非 Innodb 莫属了。Innodb 做为第三方公司所开发的存储引擎和 MySQL 遵守相同的开源 License 协议。Innodb 之所以能如此受宠主要是在于其功能方面的较多特点 1、支持事务安装 Innodb在功能方面最重要的一点就是对事务安全的支持这无疑是让Innodb成为MySQL最为流行的存储引擎之一的一个非常重要原因。而且实现了 SQL92 标准所定义的所有四个级别READ UNCOMMITTEDREAD COMMITTEDREPEATABLE READ, SERIALIZABLE。对事务安全的支持无疑让很多之前因为特殊业务要求而不得不放弃使用 MySQL 的用户转向支持MySQL以及之前对数据库选型持观望态度的用户也大大增加了对 MySQL 好感。 2、数据多版本读取 Innodb 在事务支持的同时为了保证数据的一致性已经并发时候的性能通过对 undo 信息实现了数据的多版本读取。 3、锁定机制的改进 Innodb 改变了 MyISAM 的锁机制实现了行锁。虽然 Innodb 的行锁机制的实现是通过 索引来完成的但毕竟在数据库中 99%的 SQL 语句都是要使用索引来做检索数据的。所以 行锁定机制也无疑为 Innodb 在承受高并发压力的环境下增强了不小的竞争力。 4、实现外键 Innodb 实现了外键引用这一数据库的重要特性使在数据库端控制部分数据的完整性成为可能。虽然很多数据库系统调优专家都建议不要这样做但是对于不少用户来说在数据库端加如外键控制可能仍然是成本最低的选择。 除了以上几个功能上面的亮点之外Innodb 还有很多其他一些功能特色常常带给使用者不小的惊喜同时也为 MySQL 带来了更多的客户。 在物理存储方卖弄Innodb 存储引擎也和 MyISAM 不太一样虽然也有.frm 文件来存放表结构定义相关的元数据但是表数据和索引数据是存放在一起的。至于是每个表单独存放还是所有表存放在一起完全由用户来决定通过特定配置同时还支持符号链接。
Innodb 的物理结构分为两大部分
1、数据文件表数据和索引数据
存放数据表中的数据和所有的索引数据包括主键和其他普通索引。在 Innodb 中存在了表空间tablespace这样一个概念但是他和 Oracle 的表空间又有较大的不同。首先Innodb 的表空间分为两种形式。一种是共享表空间也就是所有表和索引数据被存放在同一个表空间一个或多个数据文件中通过 innodb_data_file_path 来指定增加数据文件需要停机重启。 另外一种是独享表空间也就是每个表的数据和索引被存放在一个单独的.ibd 文件中。 虽然我们可以自行设定使用共享表空间还是独享表空间来存放我们的表但是共享表空间都是必须存在的因为 Innodb 的 undo 信息和其他一些元数据信息都是存放在共享表空间里面的。共享表空间的数据文件是可以设置为固定大小和可自动扩展大小两种形式的自动扩展形式的文件可以设置文件的最大大小和每次扩展量。在创建自动扩展的数据文件的时候建议大家最好加上最大尺寸的属性一个原因是文件系统本身是有一定大小限制的但是 Innodb 并不知道还有一个原因就是自身维护的方便。另外Innodb 不仅可以使用文 件系统还可以使用原始块设备也就是我们常说的裸设备。当我们的文件表空间快要用完的时候我们必须要为其增加数据文件当然只有共享表 空 间 有 此 操 作 。 共 享 表 空 间 增 加 数 据 文 件 的 操 作 比 较 简 单 只 需 要 在innodb_data_file_path 参数后面按照标准格式设置好文件路径和相关属性即可不过这里有一点需要注意的就是 Innodb 在创建新数据文件的时候是不会创建目录的如果指定目录不存在则会报错并无法启动。另外一个较为令人头疼的就是 Innodb 在给共享表空间增加数据文件之后必须要重启数据库系统才能生效如果是使用裸设备还需要有两次重启 。这也是我一直不太喜欢使用共享表空间而选用独享表空间的原因之一。
2、日志文件
Innodb 的日志文件和 Oracle 的 redo 日志比较类似同样可以设置多个日志组最少 2个同样采用轮循策略来顺序的写入甚至在老版本中还有和 Oracle 一样的日志归档特性 。如果你的数据库中有创建了 Innodb 的表那么千万别全部删除 innodb 的日志文件因为很可能就会让你的数据库 crash无法启动或者是丢失数据。由于 Innodb 是事务安全的存储引擎所以系统 Crash 对他来说并不能造成非常严重的损失由于有 redo 日志的存在有 checkpoint 机制的保护Innodb 完全可以通过 redo 日志将数据库 Crash 时刻已经完成但还没有来得及将数据写入磁盘的事务恢复也能够将所有部分完成并已经写入磁盘的未完成事务回滚并将数据还原。
Innodb 不仅在功能特性方面和 MyISAM 存储引擎有较大区别在配置上面也是单独处理的。在 MySQL 启动参数文件设置中Innodb 的所有参数基本上都带有前缀“innodb_”不论是 innodb 数据和日志相关还是其他一些性能事务等等相关的参数都是一样。和所有Innodb 相关的系统变量一样所有的 Innodb 相关的系统状态值也同样全部以“Innodb_”前缀。当然我们也完全可以仅仅通过一个参数skip-innodb来屏蔽 MySQL 中的 Innodb存储引擎这样即使我们在安装编译的时候将 Innodb 存储引擎安装进去了使用者也无法创建 Innodb 的表。
NDB Cluster 存储引擎简介
NDB 存储引擎也叫 NDB Cluster 存储引擎主要用于 MySQL Cluster 分布式集群环境Cluster 是 MySQL 从 5.0 版本才开始提供的新功能。这部分我们可能并不仅仅只是介绍 NDB存储引擎因为离开了 MySQL CLuster 整个环境NDB 存储引擎也将失去太多意义。 简单的说Mysql Cluster 实际上就是在无共享存储设备的情况下实现的一种内存数据库 Cluster 环境其主要是通过 NDB Cluster简称 NDB存储引擎来实现的。
一般来说一个 Mysql Cluster 的环境主要由以下三部分组成 a) 负责管理各个节点的 Manage 节点主机 管理节点负责整个 Cluster 集群中各个节点的管理工作包括集群的配置启动关闭各节点以及实施数据的备份恢复等。管理节点会获取整个 Cluster 环境中各节点的状态和错误信息并且将各 Cluster 集群中各个节点的信息反馈给整个集群中其他的所有节点。由于管理节点上保存在整个 Cluster 环境的配置同时担任了集群中各节点的基本沟通工作所以他必须是最先被启动的节点。
b) SQL 层的 SQL 服务器节点后面简称为 SQL 节点也就是我们常说的 Mysql Server 主要负责实现一个数据库在存储层之上的所有事情比如连接管理query 优化和响应cache 管理等等只有存储层的工作交给了 NDB 数据节点去处理了。也就是说在纯粹的 Mysql Cluster 环境中的 SQL 节点可以被认为是一个不需要提供任何存储引擎的 Mysql服务器因为他的存储引擎有 Cluster 环境中的 NDB 节点来担任。所以SQL 层各 Mysql 服务器的启动与普通的 Mysql 启动有一定的区别必须要添加 ndbcluster 项可以添加在my.cnf 配置文件中也可以通过启动命令行来指定。
c) Storage 层的 NDB 数据节点也就是上面说的 NDB Cluster NDB 是一个内存式存储引擎也就是说他会将所有的数据和索引数据都 load 到内存中 但也会将数据持久化到存储设备上。不过最新版本已经支持用户自己选择数据可以不全部 Load 到内存中了这对于有些数据量太大或者基于成本考虑而没有足够内存空间来存放所有数据的用户来说的确是一个大好消息。
NDB 节点主要是实现底层数据存储的功能保存 Cluster 的数据。每一个 NDB 节点保存完整数据的一部分或者一份完整的数据视节点数目和配置而定在 MySQL CLuster 里面叫做一个 fragment。而每一个 fragment正常情况来讲都会在其他的主机上面有一份或者多分完全相同的镜像存在。这些都是通过配置来完成的所以只要配置得当MysqlCluster 在存储层不会出现单点的问题。
一般来说NDB 节点被组织成一个一个的 NDB Group一个 NDB Group 实际上就是一组存有完全相同的物理数据的 NDB 节点群。上面提到了 NDB 各个节点对数据的组织可能每个节点都存有全部的数据也可能只保存一部分数据主要是受节点数目和参数来控制的。首先在 Mysql Cluster 主配置文件在管理节点上面一般为 config.ini中有一个非常重要的参数叫 NoOfReplicas这个参数指定了每一份数据被冗余存储在不同节点上面的份数该参数一般至少应该被设置成 2也只需要设置成 2 就可以了。因为正常来说两个互为冗余的节点同时出现故障的概率还是非常小的当然如果机器和内存足够多的话也可以继续增大。一个节点上面是保存所有的数据还是一部分数据还受到存储节点数目的限制。NDB 存储引擎首先保证 NoOfReplicas 参数配置的要求对数据冗余来使用存储节点然后再根据节点数目将数据分段来继续使用多余的 NDB 节点分段的数目为节点总数除以 NoOfReplicas 所得。
其他存储引擎介绍
1. Merge 存储引擎
MERGE 存储引擎在 MySQL 用户手册中也提到了也被大家认识为 MRG_MyISAM 引擎。Why因为 MERGE 存储引擎可以简单的理解为其功能就是实现了对结构相同的 MyISAM 表 通过一些特殊的包装对外提供一个单一的访问入口以达到减小应用的复杂度的目的。要创建MERGE 表不仅仅基表的结构要完全一致包括字段的顺序基表的索引也必须完全一致。
MERGE 表本身并不存储数据仅仅只是为多个基表提供一个同意的存储入口。所以在创建 MERGE 表的时候MySQL 只会生成两个较小的文件一个是.frm 的结构定义文件还有一个.MRG 文件用于存放参与 MERGE 的表的名称包括所属数据库 schema。之所以需要有所属数据库的 schema是因为 MERGE 表不仅可以实现将 Merge 同一个数据库中的表还可以Merge 不同数据库中的表只要是权限允许并且在同一个 mysqld 下面就可以进行 Merge。MERGE 表在被创建之后仍然可以通过相关命令来更改底层的基表。MERGE 表不仅可以提供读取服务也可以提供写入服务。要让 MERGE 表提供可 INSERT服务必须在在表被创建的时候就指明 INSERT 数据要被写入哪一个基表可以通过insert_method 参数来控制。如果没有指定该参数任何尝试往 MERGE 表中 INSERT 数据的操作都会出错。此外无法通过 MERGE 表直接使用基表上面的全文索引要使用全文索引 必须通过基表本身的存取才能实现。
2. Memory 存储引擎
Memory 存储引擎通过名字就很容易让人知道他是一个将数据存储在内存中的存储引擎。Memory 存储引擎不会将任何数据存放到磁盘上仅仅存放了一个表结构相关信息的.frm 文件在磁盘上面。所以一旦 MySQL Crash 或者主机 Crash 之后Memory 的表就只剩下一个结构了。Memory 表支持索引并且同时支持 Hash 和 BTree 两种格式的索引。由于是存放在内存中所以 Memory 都是按照定长的空间来存储数据的而且不支持 BLOB 和 TEXT类型的字段。Memory 存储引擎实现页级锁定。既然所有数据都存放在内存中那么他对内存的消耗量是可想而知的。在 MySQL 的用户手册上面有这样一个公式来计算 Memory 表实际需要消耗的内存大小
SUM_OVER_ALL_BTREE_KEYS(max_length_of_key sizeof(char*) * 4)SUM_OVER_ALL_HASH_KEYS(sizeof(char*) * 2)ALIGN(length_of_row1, sizeof(char*))3. BDB 存储引擎
BDB 存储引擎全称为 BerkeleyDB 存储引擎和 Innodb 一样也不是 MySQL 自己开发实现的一个存储引擎而是由 Sleepycat Software 所提供当然也是开源存储引擎同样支持事务安全。BDB 存储引擎的数据存放也是每个表两个物理文件一个.frm 和一个.db 的文件数据和索引信息都是存放在.db 文件中。此外BDB 为了实现事务安全也有自己的 redo 日 志 和 Innodb 一样也可以通过参数指定日志文件存放的位置。在锁定机制方面BDB 和 Memory存储引擎一样实现页级锁定。由于 BDB 存储引擎实现了事务安全那么他肯定也需要有自己的 check point 机 制 。BDB在每次启动的时候都会做一次 check point并且将之前的所有 redo 日志清空。在运行过程中我们也可以通过执行 flush logs 来手工对 BDB 进行 check point 操作。
4. FEDERATED 存储引擎
FEDERATED 存储引擎所实现的功能和 Oracle 的 DBLINK 基本相似主要用来提供对远程 MySQL 服务器上面的数据的访问借口。如果我们使用源码编译来安装 MySQL那么必须手工指定启用FEDERATED 存储引擎才行因为 MySQL 默认是不起用该存储引擎的。当我们创建一个 FEDERATED 表的时候仅仅在本地创建了一个表的结构定义信息的文件而已所有数据均实时取自远程的 MySQL 服务器上面的数据库。当我们通过 SQL 操作 FEDERATED 表的时候实现过程基本如下 a、SQL 调用被本地发布 b、MySQL 处理器 API数据以处理器格式 c、MySQL 客户端 API数据被转换成 SQL 调用 d、远程数据库- MySQL 客户端 API e、转换结果包如果有的话到处理器格式 f、处理器 API - 结果行或受行影响的对本地的计数
5. ARCHIVE 存储引擎
ARCHIVE 存储引擎主要用于通过较小的存储空间来存放过期的很少访问的历史数据。ARCHIVE 表不支持索引通过一个.frm 的结构定义文件一个.ARZ 的数据压缩文件还有一个.ARM 的 meta 信息文件。由于其所存放的数据的特殊性ARCHIVE 表不支持删除修改操作仅支持插入和查询操作。锁定机制为行级锁定。
6. BLACKHOLE 存储引擎
BLACKHOLE 存储引擎是一个非常有意思的存储引擎功能恰如其名就是一个“黑洞”。就像我们 unix 系统下面的“/dev/null”设备一样不管我们写入任何信息都是有去无回 。那么BLACKHOLE存储引擎对我们有什么用呢在我最初接触MySQL的时候我也有过同样的疑问不知道 MySQL 提供这样一个存储引擎给我们的用意为何但是后来在又一次数据的迁移过程中正是 BLACKHOLE 给我带来了非常大的功效。在那次数据迁移过程中由于数据需要经过一个中转的 MySQL 服务器做一些相关的转换操作然后再通过复制移植到新的服务器上 面。可当时我没有足够的空间来支持这个中转服务器的运作。这时候就显示出 BLACKHOLE的功效了他不会记录下任何数据但是会在 binlog 中记录下所有的 sql。而这些 sql 最终都是会被复制所利用并实施到最终的 slave 端。
BLACKHOLE 存储引擎其他几个用途如下 a、SQL 文件语法的验证。 b、来自二进制日志记录的开销测量通过比较允许二进制日志功能的 BLACKHOLE 的性能与禁止二进制日志功能的 BLACKHOLE 的性能。 c、因为 BLACKHOLE 本质上是一个“no-op” 存储引擎它可能被用来查找与存储引擎自身不相关的性能瓶颈。
7. CSV 存储引擎
CSV 存储引擎实际上操作的就是一个标准的 CSV 文件他不支持索引。起主要用途就是大家有些时候可能会需要通过数据库中的数据导出成一份报表文件而 CSV 文件是很多软件都支持的一种较为标准的格式所以我们可以通过先在数据库中建立一张 CVS 表然后将生成的报表信息插入到该表即可得到一份 CSV 报表文件了
