InnoDB和MyISAM存储引擎

InnoDB和MyISAM是在使用MySQL最常用的两个表类型，各有优缺点，视具体应用而定。下面是已知的两者之间的差别，仅供参考。 

 

innodb

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。 

在 http://www.innodb.com/ 上可以找到 InnoDB 最新的信息。InnoDB 手册的最新版本总是被放置在那里，并且在那里可以得到 InnoDB 的商业许可(order commercial licenses)以及支持。 

InnoDB 现在(2001年十月)在一些大的需高性能的数据库站点上被使用。著名的 Internet 新闻站点 Slashdot.org 就是使用的 InnoDB。 Mytrix, Inc. 在 InnoDB 表上存储了超过 1 TB 的数据，而且另外的一个站点在 InnoDB 表上处理着平均每秒 800 次的插入/更新的负载。 

 

MyISAM

MyISAM 是MySQL缺省存贮引擎。

每张MyISAM 桌被存放在盘在三个文件：frm 文件存放表格定义， 数据文件是MYD (MYData) ，索引文件是MYI (MYIndex) 引伸。 

 

以下是一些细节和具体实现的差别： 

1.InnoDB不支持FULLTEXT类型的索引。 

2.InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的。 

3.对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。 

4.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。 

5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性(例如外键)的表不适用。 

另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”任何一种表都不是万能的，只用恰当的针对业务类型来选择合适的表类型，才能最大的发挥MySQL的性能优势。

 

MYSQL innoDB介绍

InnoDB 是 MySQL 上第一个提供外键约束的引擎，除了提供事务处理外，InnoDB 还支持行锁，提供和 Oracle 一样的一致性的不加锁读取，能增加并发读的用户数量并提高性能，不会增加锁的数量。

InnoDB 的设计目标是处理大容量数据时最大化性能，它的 CPU 利用率是其他所有基于磁盘的关系数据库引擎中最有效率的。

InnoDB是一套放在 MySQL 后台的完整数据库系统，InnoDB 有它自己的缓冲池，能缓冲数据和索引。InnoDB还把数据和索引存放在表空间里面，可能包含好几个文件，这和 MyISAM 表完全不同，在 MyISAM 中，表被存放在单独的文件中，InnoDB表的大小只受限于操作系统文件的大小，一般为 2GB。

MySQL 的源代码中，从 3.23.34a 开始包含 InnoDB 表，并在 MySQL -Max 的二进制版本中激活。如果你使用源码版本下载，自己编译的话，需要采用 --with-innodb 选项：

./configure --with-innodb

在 MySQL-Max-3.23 上使用 InnoDB 时，必须在 my.cnf 或者 my.ini 文件中的 [mysqld] 小节指定启动参数：

innodb_data_file_path=ibdata:30M

 

InnoDB 以 GNU GPL 版本 2 的许可发布。

MySQL-Max-3.23: 这个产品可以用于生产环境使用。

MySQL-4.0: 这个是开发版本，和 3.23 相比增加了多表删除，查询结果缓冲，SSL 通信，4.0.1 为 Beta 版本。在 3.23 中，必须至少指定 innodb_data_file_path 的大小，但是在 MySQL-4.0 中这个值默认为 64MB，文件名为 ibdata1。

为了得到好的性能，必须指定 InnoDB 参数，例如：

对于一台 128MB 内存， 10GB 硬盘的 Windows NT 机器的配置如下：

[mysqld]

innodb_data_home_dir = c:/ibdata

# 数据文件必须能容下数据和索引

innodb_data_file_path = ibdata1:2000M;ibdata2:2000M

# 设置缓冲池大小为内存的 50 - 80 %

set-variable = innodb_buffer_pool_size=70M

set-variable = innodb_additional_mem_pool_size=10M

innodb_log_group_home_dir = c:/iblogs

# log_arch_dir 必须和 log_group_home_dir 一样

innodb_log_arch_dir = c:/iblogs

innodb_log_archive=0

set-variable = innodb_log_files_in_group=3

# 设置日志文件大小为缓冲池的 15%。

set-variable = innodb_log_file_size=10M

set-variable = innodb_log_buffer_size=8M

# 如果丢失最近的几个事务影响不大的话，设置 flush_log_at_trx_commit 为 0。

innodb_flush_log_at_trx_commit=1

set-variable = innodb_file_io_threads=4

set-variable = innodb_lock_wait_timeout=50

注意 InnoDB 不会自己建立目录，你必须使用操作系统命令建立目录，并注意 MySQL 的权限。第一次运行 MySQL 时，建议使用命令行方式。在 Windows 下，用命令行开启：

C:/MYSQL>mysqld-max --standalone --console

在 Windows 下设置配置文件的原则是：

my.cnf 和 my.ini 只能是一个有效。

my.cnf 放在 C: 根目录下， my.ini 文件放在 WINDIR 目录下，C:/WINDOWS 或者 C:/WINNT。

在 Linux 下面，初始配置文件按下面的顺序搜索：

/etc/my.cnf 全局选项

COMPILATION_DATADIR/my.cnf 服务器范围的选项

defaults-extra-file 采用 --defaults-extra-file=.... 的文件

~/.my.cnf 用户指定的选项

假设你有一台 512MB 内存，三台 20GB 硬盘(路径分别为："/"，"/dr2"，"/dr3“)的服务器，设置的例子为：

[mysqld]

innodb_data_home_dir = /

innodb_data_file_path = ibdata/ibdata1:2000M;dr2/ibdata/ibdata2:2000M

set-variable = innodb_buffer_pool_size=350M

set-variable = innodb_additional_mem_pool_size=20M

innodb_log_group_home_dir = /dr3/iblogs

innodb_log_arch_dir = /dr3/iblogs

innodb_log_archive=0

set-variable = innodb_log_files_in_group=3

set-variable = innodb_log_file_size=50M

set-variable = innodb_log_buffer_size=8M

innodb_flush_log_at_trx_commit=1

set-variable = innodb_file_io_threads=4

set-variable = innodb_lock_wait_timeout=50

#innodb_flush_method=fdatasync

#innodb_fast_shutdown=1

#set-variable = innodb_thread_concurrency=5

为了提升性能，我们把日志文件和数据文件放在不同的磁盘，另外还可以采用裸的磁盘分区来存储数据以提升性能。需要提醒的是，在 Linux x86 上不要把内存设置太高，glibc 会把进程堆增长到线程堆栈之上，能把服务器给搞垮，下面的值接近于 2GB 时就很危险：

innodb_buffer_pool_size + key_buffer +

max_connections * (sort_buffer + record_buffer) + max_connections * 2 MB

每个线程将使用 2MB(二进制版本为 256 KB) 的堆栈，在最坏的情况下，还会使用 sort_buffer + record_buffer 的附加内存。

后续的文章，我们还将介绍 InnoDB 表的建立，MyISAM 到 InnoDB 的转换，外键约束的使用，自动增长列的操作，InnoDB 数据库的备份和恢复，事务的使用，性能调优等内容。

 

MySQL InnoDB的性能问题讨论

MySQL最为人垢病的缺点就是缺乏事务的支持，MyISAM 性能虽然出众，不是没有代价的，InnoDB 又如何呢？InnoDB 的磁盘性能很令人担心，MySQL 缺乏良好的 tablespace 真是天大的缺陷！ 

InnoDB的表空间分成三种，一种是裸设备，一种是若干个 ibdata 文件(缺省方式)，再一种是 Per-Table 文件，第一种用得少，第二种显然比第三种效率更差，本文的讨论基于 Per-Table，也即innodb_file_per_table 配置参数。 

现象重现：导出一个几百万行数据、带若干索引、有过频繁更新的表出来再导入，如果能以真实环境下的表来做测试就更理想，到 data 目录下观察对应的数据文件的 size 增长情况，会发现前 1G 速度相当令人满意，可是越往后效率越低，到后面基本就是蜗牛般的速度了。 

不是只有导入才会让你慢得受不了，alter column/index 都会这样。

InnoDB 跟磁盘相关的文件存储，可以分成两个部分，一个是日志文件，另一个是数据文件。当有频繁的 INSERT/UPDATE 操作的时候，InnoDB 需要分别写入这两个文件，日志文件是顺序操作，数据文件包括了表数据和索引数据两个部分(和 MyISAM 直接拆开成表文件和索引文件不同，InnoDB 的表和索引是在同一个文件当中的)。 

InnoDB 的索引用的是 BTREE 格式，如果当前更新的记录影响到索引的变化，逻辑上就存在三个操作，从原来的 BTREE 找到并摘除原来这行的记录并做调整、插入行数据、根据新数据查找 BTREE 相应的位置并重新插入新索引信息，假设索引数为 N，相应的逻辑操作数就为 1 + 2*N，显然这些信息不能保证在同一个磁盘连续空间上，因此需要 1 + 2*N 次的磁头移动，行数越大、文件尺寸越大，磁头的移动幅度也就可能越大，带来的后果显然是极差的磁盘 IO 效率。 

MySQL 对于 MyISAM 的的磁盘 IO 优化是如何建议的呢？使用符号链接将表文件和索引文件分别指向不同的不同的目录，分散到不同的磁盘上以增加系统的访问速度。这种优化方式，在 InnoDB 上完全没有可能性！ 

如果有 tablespace 支持，磁盘效率问题就好解决了，一如商业数据库的做法，将日志、表文件、索引文件分别分布到不同的表空间也就是物理磁盘上，可是 MySQL 一直到 5.1 都没有提供 tablespace 功能，仅在 NDB/NDBCLUSTER 中才提供，但是 - "CREATE TABLESPACE was added in MySQL 5.1.6. In MySQL 5.1, it is useful only with Disk Data storage for MySQL Cluster."。 不知道 Yahoo 等大网站是怎么解决这个难题的。考虑切换到 PostgreSQL 中。

 

 

转自：http://www.unixaid.info/index.php/unixtecspt/37-db/528-innodbmyisam