MySQL数据表在系统中表现形式有:ISAM、MyISAM、MERGE、BDB、InnoDB和HEAP。每种数据表在文件系统中都有不同的表示方式,有一个共同点就是每种数据表至少有一个存放数据表结构定义的.frm文件。ISAM数据表是最原始的数据表(.frm,.ISD,.ISM),MyISAM数据表是ISAM数据表的继承者。InnoDB由于采用表空间的概念来管理数据表,所以它只有一个与数据表对应.frm文件,同一目录下的其它文件表示为表空间,存储数据表的数据和索引。
数据目录是用来存放数据表和相关信息的地方,是数据库的核心。在WINDOWS系统上,数据目录的位置默认是在c:/mysql/data中。数据目录除存放数据库文件外,还会存放日志文件,状态文件,配置文件,DES密钥文件或服务器的SSL证书与密钥文件等。在MySQL中,每个数据库其实就是在数据目录下一个子目录,show databases命令相当于列出数据目录中的目录清单。所以可以通过操作数据目录中的子目录来新建(create)、删除(drop)数据库。但drop database db_name命令不能删除db_name目录中创建的其它非数据表文件;且由于InnoDB是表空间来管理数据表,所以不能用rm或del命令删除InnoDB的数据表。
上面提到的四种存储引擎都有各自适用的环境,这取决于它们独有的一些特征。主要体现在性能、事务、并发控制、参照完整性、缓存、 故障恢复,备份及回存等几个方面。
目前比较普及的存储引擎是MyISAM和InnoDB.而MyISAM又是绝大部分Web应用的首选。MyISAM与InnoDB的主要的不同点在于性能和事务控制上。
MyISAM是早期ISAM(Indexed Sequential Access Method,我现在用的MySQL5.0已经不支持ISAM了)的扩展实现,ISAM被设计为适合处理读频率远大于写频率这样一种情况,因此ISAM以及后来的MyISAM都没有考虑对事务的支持,排除了TPM,不需要事务记录,ISAM的查询效率相当可观,而且内存占用很少。MyISAM在继承了这类优点的同时,与时俱进的提供了大量实用的新特性和相关工具。例如考虑到并发控制,提供了表级锁,虽然MyISAM本身不支持容错,但可以通过myisamchk进行故障恢复。而且由于MyISAM是每张表使用各自独立的存储文件(MYD数据文件和MYI索引文件),使得备份及恢复十分方便(拷贝覆盖即可),而且还支持在线恢复。所以如果你的应用是不需要事务,处理的只是基本的CRUD操作,那么MyISAM是不二选择
InnoDB被设计成适用于高并发读写的情况.使用MVCC(Multi-Version Concurrency Control)以及行级锁来提供遵从ACID的事务支持。InnoDB支持外键参照完整性,具备故障恢复能力。另外 InnoDB的性能其实还是不错的,特别是在处理大数据量的情况下,用官方的话说就是: InnoDB的CPU效率是其他基于磁盘的关系数据库存储引擎所不能比的。不过InnoDB的备份恢复要麻烦一点,除非你使用了4.1以后版本提供的Mulit-tablespace支持,因为InnoDB和MyISAM不同,他的数据文件并不是独立对应于每张表的。而是使用的共享表空间,简单的拷贝覆盖方法对他不适用,必须在停掉MYSQL后对其进行数据恢复。使用Per-Table Tablespacesd,使其每张表对应一个独立的表空间文件,则情况要简单很多。
一般来说,如果需要事务支持,并且有较高的并发读写频率,InnoDB是不错的选择。要是并发读写频率不高的话,其实可以考虑BDB,但由于在MySQL5.1及其以后版本中,将不再提供BDB支持。这个选项也就没有了
至于Heap和BDB(Berkeley DB),相对来说,普及率不如前两种,但在有些情况下,还是挺适用的
Heap存储引擎就是将数据存储在内存中,由于没有磁盘I./O的等待,速度极快。但由于是内存存储引擎,所做的任何修改在服务器重启后都将消失。Heap挺适合做测试的时候使用
BDB是MySQL第一款事务安全的存储引擎。在Berkeley DB database library的基础上建立,同样是事务安全的,但BDB的普及率显然不及InnoDB,因为大多数在MySQL中寻找支持事务的存储引擎的同时也在找支持MVCC或是行级锁定存储引擎,而BDB只支持Page-level Lock。
附上一张《High Performance MySQL》 中的各存储引擎的特性表
Attribute |
MyISAM |
Heap |
BDB |
InnoDB |
Transactions |
No |
No |
Yes |
Yes |
Lock granularity |
Table |
Table |
Page (8 KB) |
Row |
Storage |
Split files |
In-memory |
Single file per table |
Tablespace(s) |
Isolation levels |
None |
None |
Read committed |
All |
Portable format |
Yes |
N/A |
No |
Yes |
Referential integrity |
No |
No |
No |
Yes |
Primary key with data |
No |
No |
Yes |
Yes |
MySQL caches data records |
No |
Yes |
Yes |
Yes |
Availability |
All versions |
All versions |
MySQL-Max |
All Versions |
InnoDB 给 MySQL 提供了具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。InnoDB 提供了行锁(locking on row level),提供与 Oracle 类型一致的不加锁读取(non-locking read in SELECTs)。这些特性均提高了多用户并发操作的性能表现。在InnoDB表中不需要扩大锁定(lock escalation),因为 InnoDB 的列锁定(row level locks)适宜非常小的空间。InnoDB 是 MySQL 上第一个提供外键约束(FOREIGN KEY constraints)的表引擎。
InnoDB 的设计目标是处理大容量数据库系统,它的 CPU 利用率是其它基于磁盘的关系数据库引擎所不能比的。在技术上,InnoDB 是一套放在 MySQL 后台的完整数据库系统,InnoDB 在主内存中建立其专用的缓冲池用于高速缓冲数据和索引。 InnoDB 把数据和索引存放在表空间里,可能包含多个文件,这与其它的不一样,举例来说,在 MyISAM 中,表被存放在单独的文件中。InnoDB 表的大小只受限于操作系统的文件大小,一般为 2 GB。
InnoDB所有的表都保存在同一个数据文件 ibdata1 中(也可能是多个文件,或者是独立的表空间文件),相对来说比较不好备份,免费的方案可以是拷贝数据文件、备份 binlog,或者用 mysqldump。
MyISAM
MyISAM 是MySQL缺省存贮引擎 .
每张MyISAM 表被存放在三个文件 。frm 文件存放表格定义。 数据文件是MYD (MYData) 。 索引文件是MYI (MYIndex) 引伸。
因为MyISAM相对简单,所以在效率上要优于InnoDB..小型应用使用MyISAM是不错的选择.
MyISAM表是保存成文件的形式,在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦
MyIASM是IASM表的新版本,有如下扩展:
二进制层次的可移植性。
NULL列索引。
对变长行比ISAM表有更少的碎片。
支持大文件。
更好的索引压缩。
更好的键码统计分布。
更好和更快的auto_increment处理。
1.MySQL最大的优势在于MyISAM引擎下的简单SELECT,INSERT和UPDATE快速操作
2.MyISAM类型的数据文件可以在不同操作系统中COPY,这点很重要,布署的时候方便点。
以下是一些细节和具体实现的差别:
1.InnoDB不支持FULLTEXT类型的索引。
2.InnoDB 中不保存表的具体行数,也就是说,执行select count(*) from table时,InnoDB要扫描一遍整个表来计算有多少行,但是MyISAM只要简单的读出保存好的行数即可。注意的是,当count(*)语句包含 where条件时,两种表的操作是一样的。
3.对于AUTO_INCREMENT类型的字段,InnoDB中必须包含只有该字段的索引,但是在MyISAM表中,可以和其他字段一起建立联合索引。[建表时,mysql可能自动找auto_increment的字段,并据其建立索引,对MyISAM和Innodb都成立]
4.DELETE FROM table时,InnoDB不会重新建立表,而是一行一行的删除。[也即MyISAM是通过重新建表、覆盖原来的数据文件.MYD来删除表。与此同时,索引文件.MYI也会重新生成。参见下文《mysql错误:Table XXX is marked as crashed and should be repaired[转]》]
5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的,解决方法是首先把InnoDB表改成MyISAM表,导入数据后再改成InnoDB表,但是对于使用的额外的InnoDB特性(例如外键)的表不适用。
另外,InnoDB表的行锁也不是绝对的,如果在执行一个SQL语句时MySQL不能确定要扫描的范围,InnoDB表同样会锁全表,例如update table set num=1 where name like “%aaa%”
以暂对存储引擎的认识,觉得 InnoDB 支持外键,在数据量可以用“庞大”来形容时,在有良好的 INDEX 的基础上,InnoDB 的查询速度应该比 MyISAM 要快。
在 Falcon 有稳定版本前,我想 MyISAM 是一个可用的选择方案。
任何一种表都不是万能的,只用恰当的针对业务类型来选择合适的表类型,才能最大的发挥MySQL的性能优势。