MySQL数据库存储引擎详解

MySQL数据库存储引擎详解,第1张

存储引擎是什么?

MySQL中的数据用各种不同的技术存储在文件(或者内存)中 这些技术中的每一种技术都使用不同的存储机制 索引技巧 锁定水平并且最终提供广泛的不同的功能和能力 通过选择不同的技术 你能够获得额外的速度或者功能 从而改善你的应用的整体功能

例如 如果你在研究大量的临时数据 你也许需要使用内存存储引擎 内存存储引擎能够在内存中存储所有的表格数据 又或者 你也许需要一个支持事务处理的数据库(以确保事务处理不成功时数据的回退能力)

这些不同的技术以及配套的相关功能在MySQL中被称作存储引擎(也称作表类型) MySQL默认配置了许多不同的存储引擎 可以预先设置或者在MySQL服务器中启用 你可以选择适用于服务器 数据库和表格的存储引擎 以便在选择如何存储你的信息 如何检索这些信息以及你需要你的数据结合什么性能和功能的时候为你提供最大的灵活性

选择如何存储和检索你的数据的这种灵活性是MySQL为什么如此受欢迎的主要原因 其它数据库系统(包括大多数商业选择)仅支持一种类型的数据存储 遗憾的是 其它类型的数据库解决方案采取的 一个尺码满足一切需求 的方式意味着你要么就牺牲一些性能 要么你就用几个小时甚至几天的时间详细调整你的数据库 使用MySQL 我们仅需要修改我们使用的存储引擎就可以了

在这篇文章中 我们不准备集中讨论不同的存储引擎的技术方面的问题(尽管我们不可避免地要研究这些因素的某些方面) 相反 我们将集中介绍这些不同的引擎分别最适应哪种需求和如何启用不同的存储引擎 为了实现这个目的 在介绍每一个存储引擎的具体情况之前 我们必须要了解一些基本的问题

如何确定有哪些存储引擎可用

你可以在MySQL(假设是MySQL服务器 以上版本)中使用显示引擎的命令得到一个可用引擎的列表

mysql> show engines   + + + +    | Engine     | Support | Comment                                                    |    + + + +    | MyISAM     | DEFAULT | Default engine as of MySQL   with great performance     |    | HEAP       | YES     | Alias for MEMORY                                           |    | MEMORY     | YES     | Hash based  stored in memory  useful for temporary tables  |    | MERGE      | YES     | Collection of identical MyISAM tables                      |    | MRG_MYISAM | YES     | Alias for MERGE                                            |    | ISAM       | NO      | Obsolete storage engine  now replaced by MyISAM            |    | MRG_ISAM   | NO      | Obsolete storage engine  now replaced by MERGE             |    | InnoDB     | YES     | Supports transactions  row level locking  and foreign keys |    | INNOBASE   | YES     | Alias for INNODB                                           |    | BDB        | NO      | Supports transactions and page level locking               |    | BERKELEYDB | NO      | Alias for BDB                                              |    | NDBCLUSTER | NO      | Clustered  fault tolerant  memory based tables             |    | NDB        | NO      | Alias for NDBCLUSTER                                       |    | EXAMPLE    | NO      | Example storage engine                                     |    | ARCHIVE    | NO      | Archive storage engine                                     |    | CSV        | NO      | CSV storage engine                                         |    + + + +     rows in set (  sec)  

这个表格显示了可用的数据库引擎的全部名单以及在当前的数据库服务器中是否支持这些引擎

对于MySQL 以前版本 可以使用mysql>show variables like have_% (显示类似 have_% 的变量):

mysql> show variables like  have_%      + + +     | Variable_name    | Value    |     + + +     | have_bdb         | YES      |     | have_crypt       | YES      |     | have_innodb      | DISABLED |     | have_isam        | YES      |     | have_raid        | YES      |     | have_symlink     | YES      |     | have_openssl     | YES      |     | have_query_cache | YES      |     + + +      rows in set (  sec)    

你可以通过修改设置脚本中的选项来设置在MySQL安装软件中可用的引擎 如果你在使用一个预先包装好的MySQL二进制发布版软件 那么 这个软件就包含了常用的引擎 然而 需要指出的是 如果你要使用某些不常用的引擎 特别是CSV RCHIVE(存档)和BLACKHOLE(黑洞)引擎 你就需要手工重新编译MySQL源码

使用一个指定的存储引擎

你可以使用很多方法指定一个要使用的存储引擎 最简单的方法是 如果你喜欢一种能满足你的大多数数据库需求的存储引擎 你可以在MySQL设置文件中设置一个默认的引擎类型(使用storage_engine 选项)或者在启动数据库服务器时在命令行后面加上 default storage engine或 default table type选项

更灵活的方式是在随MySQL服务器发布同时提供的MySQL客户端时指定使用的存储引擎 最直接的方式是在创建表时指定存储引擎的类型 向下面这样:

CREATE TABLE mytable (id int title char( )) ENGINE = INNODB

你还可以改变现有的表使用的存储引擎 用以下语句:

ALTER TABLE mytable ENGINE = MyISAM

然而 你在以这种方式修改表格类型的时候需要非常仔细 因为对不支持同样的索引 字段类型或者表大小的一个类型进行修改可能使你丢失数据 如果你指定一个在你的当前的数据库中不存在的一个存储引擎 那么就会创建一个MyISAM(默认的)类型的表

各存储引擎之间的区别

为了做出选择哪一个存储引擎的决定 我们首先需要考虑每一个存储引擎提供了哪些不同的核心功能 这种功能使我们能够把不同的存储引擎区别开来 我们一般把这些核心功能分为四类:支持的字段和数据类型 锁定类型 索引和处理 一些引擎具有能过促使你做出决定的独特的功能 我们一会儿再仔细研究这些具体问题

字段和数据类型

虽然所有这些引擎都支持通用的数据类型 例如整型 实型和字符型等 但是 并不是所有的引擎都支持其它的字段类型 特别是BLOG(二进制大对象)或者TEXT文本类型 其它引擎也许仅支持有限的字符宽度和数据大小

这些局限性可能直接影响到你可以存储的数据 同时也可能会对你实施的搜索的类型或者你对那些信息创建的索引产生间接的影响 这些区别能够影响你的应用程序的性能和功能 因为你必须要根据你要存储的数据类型选择对需要的存储引擎的功能做出决策

锁定

数据库引擎中的锁定功能决定了如何管理信息的访问和更新 当数据库中的一个对象为信息更新锁定了 在更新完成之前 其它处理不能修改这个数据(在某些情况下还不允许读这种数据)

锁定不仅影响许多不同的应用程序如何更新数据库中的信息 而且还影响对那个数据的查询 这是因为查询可能要访问正在被修改或者更新的数据 总的来说 这种延迟是很小的 大多数锁定机制主要是为了防止多个处理更新同一个数据 由于向数据中插入信息和更新信息这两种情况都需要锁定 你可以想象 多个应用程序使用同一个数据库可能会有很大的影响

不同的存储引擎在不同的对象级别支持锁定 而且这些级别将影响可以同时访问的信息 得到支持的级别有三种:表锁定 块锁定和行锁定 支持最多的是表锁定 这种锁定是在MyISAM中提供的 在数据更新时 它锁定了整个表 这就防止了许多应用程序同时更新一个具体的表 这对应用很多的多用户数据库有很大的影响 因为它延迟了更新的过程

页级锁定使用Berkeley DB引擎 并且根据上载的信息页( KB)锁定数据 当在数据库的很多地方进行更新的时候 这种锁定不会出现什么问题 但是 由于增加几行信息就要锁定数据结构的最后 KB 当需要增加大量的行 也别是大量的小型数据 就会带来问题

行级锁定提供了最佳的并行访问功能 一个表中只有一行数据被锁定 这就意味着很多应用程序能够更新同一个表中的不同行的数据 而不会引起锁定的问题 只有InnoDB存储引擎支持行级锁定

建立索引

建立索引在搜索和恢复数据库中的数据的时候能够显著提高性能 不同的存储引擎提供不同的制作索引的技术 有些技术也许会更适合你存储的数据类型

有些存储引擎根本就不支持索引 其原因可能是它们使用基本表索引(如MERGE引擎)或者是因为数据存储的方式不允许索引(例如FEDERATED或者BLACKHOLE引擎)

事务处理

事务处理功能通过提供在向表中更新和插入信息期间的可靠性 这种可靠性是通过如下方法实现的 它允许你更新表中的数据 但仅当应用的应用程序的所有相关 *** 作完全完成后才接受你对表的更改 例如 在会计处理中每一笔会计分录处理将包括对借方科目和贷方科目数据的更改 你需要要使用事务处理功能保证对借方科目和贷方科目的数据更改都顺利完成 才接受所做的修改 如果任一项 *** 作失败了 你都可以取消这个事务处理 这些修改就不存在了 如果这个事务处理过程完成了 我们可以通过允许这个修改来确认这个 *** 作

lishixinzhi/Article/program/MySQL/201311/29301

一般情况下,mysql会默认提供多种存储引擎,你可以通过下面的查看:

看你的mysql现在已提供什么存储引擎:

mysql>show engines

看你的mysql当前默认的存储引擎:

mysql>show variables like '%storage_engine%'

你要看某个表用了什么引擎(在显示结果里参数engine后面的就表示该表当前用的存储引擎):

mysql>show create table 表名

MySQL数据库引擎详解

作为Java程序员,MySQL数据库大家平时应该都没少使用吧,对MySQL数据库的引擎应该也有所了解,这篇文章就让我详细的说说MySQL数据库的Innodb和MyIASM两种引擎以及其索引结构。也来巩固一下自己对这块知识的掌握。

Innodb引擎

Innodb引擎提供了对数据库ACID事务的支持,并且实现了SQL标准的四种隔离级别,关于数据库事务与其隔离级别的内容请见数据库事务与其隔

离级别这篇文章。该引擎还提供了行级锁和外键约束,它的设计目标是处理大容量数据库系统,它本身其实就是基于MySQL后台的完整数据库系统,MySQL

运行时Innodb会在内存中建立缓冲池,用于缓冲数据和索引。但是该引擎不支持FULLTEXT类型的索引,而且它没有保存表的行数,当SELECT

COUNT(*) FROM

TABLE时需要扫描全表。当需要使用数据库事务时,该引擎当然是首选。由于锁的粒度更小,写 *** 作不会锁定全表,所以在并发较高时,使用Innodb引擎

会提升效率。但是使用行级锁也不是绝对的,如果在执行一个SQL语句时MySQL不能确定要扫描的范围,InnoDB表同样会锁全表。

MyIASM引擎

MyIASM是MySQL默认的引擎,但是它没有提供对数据库事务的支持,也不支持行级锁和外键,因此当INSERT(插入)或UPDATE(更

新)数据时即写 *** 作需要锁定整个表,效率便会低一些。不过和Innodb不同,MyIASM中存储了表的行数,于是SELECT COUNT(*)

FROM

TABLE时只需要直接读取已经保存好的值而不需要进行全表扫描。如果表的读 *** 作远远多于写 *** 作且不需要数据库事务的支持,那么MyIASM也是很好的选

择。

两种引擎的选择

大尺寸的数据集趋向于选择InnoDB引擎,因为它支持事务处理和故障恢复。数据库的大小决定了故障恢复的时间长短,InnoDB可以利用事务日志

进行数据恢复,这会比较快。主键查询在InnoDB引擎下也会相当快,不过需要注意的是如果主键太长也会导致性能问题,关于这个问题我会在下文中讲到。大

批的INSERT语句(在每个INSERT语句中写入多行,批量插入)在MyISAM下会快一些,但是UPDATE语句在InnoDB下则会更快一些,尤

其是在并发量大的时候。

Index——索引

索引(Index)是帮助MySQL高效获取数据的数据结构。MyIASM和Innodb都使用了树这种数据结构做为索引,关于树我也曾经写过一篇文章树是一种伟大的数据结构,只是自己的理解,有兴趣的朋友可以去阅读。下面我接着讲这两种引擎使用的索引结构,讲到这里,首先应该谈一下B-Tree和B+Tree。

B-Tree和B+Tree

B+Tree是B-Tree的变种,那么我就先讲B-Tree吧,相信大家都知道红黑树,这是我前段时间学《算法》一书时,实现的一颗红黑树,大家

可以参考。其实红黑树类似2,3-查找树,这种树既有2叉结点又有3叉结点。B-Tree也与之类似,它的每个结点做多可以有d个分支(叉),d称为B-

Tree的度,如下图所示,它的每个结点可以有4个元素,5个分支,于是它的度为5。B-Tree中的元素是有序的,比如图中元素7左边的指针指向的结点

中的元素都小于7,而元素7和16之间的指针指向的结点中的元素都处于7和16之间,正是满足这样的关系,才能高效的查找:首先从根节点进行二分查找,找

到就返回对应的值,否则就进入相应的区间结点递归的查找,直到找到对应的元素或找到null指针,找到null指针则表示查找失败。这个查找是十分高效

的,其时间复杂度为O(logN)(以d为底,当d很大时,树的高度就很低),因为每次检索最多只需要检索树高h个结点。

接下来就该讲B+Tree了,它是B-Tree的变种,如下面两张图所示:

vcHLx/i85LLp0a/Qp8LKoaM8L3A+DQo8aDMgaWQ9"myisam引擎的索引结构">MyISAM引擎的索引结构

MyISAM引擎的索引结构为B+Tree,其中B+Tree的数据域存储的内容为实际数据的地址,也就是说它的索引和实际的数据是分开的,只不过是用索引指向了实际的数据,这种索引就是所谓的非聚集索引。

Innodb引擎的索引结构

MyISAM引擎的索引结构同样也是B+Tree,但是Innodb的索引文件本身就是数据文件,即B+Tree的数据域存储的就是实际的数据,这种索引就是聚集索引。这个索引的key就是数据表的主键,因此InnoDB表数据文件本身就是主索引。

因为InnoDB的数据文件本身要按主键聚集,所以InnoDB要求表必须有主键(MyISAM可以没有),如果没有显式指定,则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键,如果不存在这种列,则MySQL自动为InnoDB表生成一个隐含字段作为主键,这个字段长度为6个字节,类型为长整形。

并且和MyISAM不同,InnoDB的辅助索引数据域存储的也是相应记录主键的值而不是地址,所以当以辅助索引查找时,会先根据辅助索引找到主

键,再根据主键索引找到实际的数据。所以Innodb不建议使用过长的主键,否则会使辅助索引变得过大。建议使用自增的字段作为主键,这样B+Tree的

每一个结点都会被顺序的填满,而不会频繁的分裂调整,会有效的提升插入数据的效率。

 查看MySQL 支持的存储引擎有三种语句格式:

格式一:SHOW ENGINES;

格式二:SHOW ENGINES\g

格式三:SHOW ENGINES\G

这三种格式区别仅在于使用的“结束符”不同,这会导致“命令执行结果的显示”不同。其中“\G”的显示效果最好,对所支持的各种存储引擎会从“引擎名称”、“是否支持该引擎”、“关于该引擎的说明、评论”、“是不是支持事务”、“该引擎支持的分布式是否支持XA规范”、“是否支持事务处理中的保存点”等方面逐个地、详细地显示出来;使用“;”和“\g”作用相同,仅简单显示各个存储引擎的信息。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/7544743.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-06
下一篇 2023-04-06

发表评论

登录后才能评论

评论列表(0条)

保存