MySQL数据库存储引擎详解

存储引擎是什么？

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

五 索引分类

直接创建索引和间接创建索引

直接创建索引 CREATE INDEX mycolumn_index ON mytable (myclumn)

间接创建索引 定义主键约束或者唯一性键约束 可以间接创建索引

普通索引和唯一性索引

普通索引 CREATE INDEX mycolumn_index ON mytable (myclumn)

唯一性索引 保证在索引列中的全部数据是唯一的 对聚簇索引和非聚簇索引都可以使用

CREATE UNIQUE COUSTERED INDEX myclumn_cindex ON mytable(mycolumn)

单个索引和复合索引

单个索引 即非复合索引

复合索引 又叫组合索引 在索引建立语句中同时包含多个字段名 最多 个字段

CREATE INDEX name_index ON username(firstname lastname)

聚簇索引和非聚簇索引(聚集索引 群集索引)

聚簇索引 物理索引 与基表的物理顺序相同 数据值的顺序总是按照顺序排列

CREATE CLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn) WITH

ALLOW_DUP_ROW(允许有重复记录的聚簇索引)

非聚簇索引 CREATE UNCLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn)

六 索引的使用

当字段数据更新频率较低 查询使用频率较高并且存在大量重复值是建议使用聚簇索引

经常同时存取多列 且每列都含有重复值可考虑建立组合索引

复合索引的前导列一定好控制好 否则无法起到索引的效果 如果查询时前导列不在查询条件中则该复合索引不会被使用 前导列一定是使用最频繁的列

多表 *** 作在被实际执行前 查询优化器会根据连接条件 列出几组可能的连接方案并从中找出系统开销最小的最佳方案 连接条件要充份考虑带有索引的表 行数多的表内外表的选择可由公式 外层表中的匹配行数*内层表中每一次查找的次数确定 乘积最小为最佳方案

where子句中对列的任何 *** 作结果都是在sql运行时逐列计算得到的 因此它不得不进行表搜索 而没有使用该列上面的索引如果这些结果在查询编译时就能得到 那么就可以被sql优化器优化 使用索引 避免表搜索(例 select * from record where substring(card_no )=

&&select * from record where card_no like % )任何对列的 *** 作都将导致表扫描 它包括数据库函数 计算表达式等等 查询时要尽可能将 *** 作移至等号右边

where条件中的 in 在逻辑上相当于 or 所以语法分析器会将in ( ′ ′)转化为column= ′ or column= ′来执行 我们期望它会根据每个or子句分别查找 再将结果相加 这样可以利用column上的索引但实际上它却采用了 or策略 即先取出满足每个or子句的行 存入临时数据库的工作表中 再建立唯一索引以去掉重复行 最后从这个临时表中计算结果 因此 实际过程没有利用column上索引 并且完成时间还要受tempdb数据库性能的影响 in or子句常会使用工作表 使索引失效如果不产生大量重复值 可以考虑把子句拆开拆开的子句中应该包含索引

要善于使用存储过程 它使sql变得更加灵活和高效

lishixinzhi/Article/program/MySQL/201311/29603

数据库引入了索引

用户对数据库最频繁的 *** 作是进行数据查询 一般情况下 数据库在进行查询 *** 作时需要对整个表进行数据搜索 当表中的数据很多时 搜索数据就需要很长的时间 这就造成了服务器的资源浪费 为了提高检索数据的能力 数据库引入了索引机制

有关 索引 的比喻

从某种程度上 可以把数据库看作一本书 把索引看作书的目录 通过目录查找书中的信息 显然较没有目录的书方便 快捷

数据库索引实际是什么?(两部分组成)

索引是一个单独的 物理的数据库结构 它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单

索引在表中的角色

一个表的存储是由两部分组成的 一部分用来存放表的数据页面 另一部分存放索引页面 索引就存放在索引页面上

索引高效原理

通常 索引页面相对于数据页面来说小得多 当进行数据检索时 系统先搜索索引页面 从中找到所需数据的指针 再直接通过指针从数据页面中读取数据

索引的分类

在SQL Server 的数据库中按存储结构的不同将索引分为两类 簇索引(Clustered Index)和非簇索引(Nonclustered Index)

( )簇索引对表的物理数据页中的数据按列进行排序 然后再重新存储到磁盘上 即簇索引与数据是混为一体 的它的叶节点中存储的是实际的数据 由于簇索引对表中的数据一一进行了排序 因此用簇索引查找数据很快 但由于簇索引将表的所有数据完全重新排列了 它所需要的空间也就特别大 大概相当于表中数据所占空间的 % 表的数据行只能以一种排序方式存储在磁盘上 所以一个表只能有一个簇索引

( )非簇索引具有与表的数据完全分离的结构 使用非簇索引不用将物理数据页中的数据按列排序 非簇索引的叶节点中存储了组成非簇索引的关键字的值和行定位器 行定位器的结构和存储内容取决于数据的存储方式 如果数据是以簇索引方式存储的 则行定位器中存储的是簇索引的索引键如果数据不是以簇索引方式存储的 这种方式又称为堆存储方式(Heap Structure) 则行定位器存储的是指向数据行的指针 非簇索引将行定位器按关键字的值用一定的方式排序 这个顺序与表的行在数据页中的排序是不匹配的 由于非簇索引使用索引页存储因此它比簇索引需要更多的存储空间且检索效率较低但一个表只能建一个簇索引 当用户需要建立多个索引时就需要使用非簇索引了

小结 Clustered Index 是与物理数据混在一起并对物理数据进重排 就像使用拼音查字典Unclustered Index 是与物理数据完全分离的 利用额外空间对关键字进行重排 就像使用部首查字典

数据库索引应用

一 索引的概念

索引就是加快检索表中数据的方法 数据库的索引类似于书籍的索引 在书籍中 索引允许用户不必翻阅完整个书就能迅速地找到所需要的信息 在数据库中 索引也允许数据库程序迅速地找到表中的数据 而不必扫描整个数据库

二 索引的特点

索引可以加快数据库的检索速度

索引降低了数据库插入 修改 删除等维护任务的速度

索引创建在表上 不能创建在视图上

索引既可以直接创建 也可以间接创建

可以在优化隐藏中 使用索引

使用查询处理器执行SQL语句 在一个表上 一次只能使用一个索引

其他

三 索引的优点

创建唯一性索引 保证数据库表中每一行数据的唯一性

大大加快数据的检索速度 这也是创建索引的最主要的原因

加速表和表之间的连接 特别是在实现数据的参考完整性方面特别有意义

在使用分组和排序子句进行数据检索时 同样可以显著减少查询中分组和排序的时间

通过使用索引 可以在查询的过程中使用优化隐藏器 提高系统的性能

四 索引的缺点

创建索引和维护索引要耗费时间 这种时间随着数据量的增加而增加

索引需要占物理空间 除了数据表占数据空间之外 每一个索引还要占一定的物理空间 如果要建立聚簇索引 那么需要的空间就会更大

当对表中的数据进行增加 删除和修改的时候 索引也要动态的维护 降低了数据的维护速度

lishixinzhi/Article/program/MySQL/201311/29604

---