mysql两大存储引擎的区别与选择

转载自：  http://www.cnblogs.com/ggjucheng/archive/2012/11/11/2765469.html 
MyISAM

MyISAM表是独立于操作系统的，这说明可以轻松地将其从Windows服务器移植到Linux服务器；每当我们建立一个MyISAM引擎的表时，就会在本地磁盘上建立三个文件，文件名就是表明。例如，我建立了一个MyISAM引擎的tb_Demo表，那么就会生成以下三个文件：<p>1.tb_demo.frm，存储表定义；
2.tb_demo.MYD，存储数据；
3.tb_demo.MYI，存储索引。</p><p>MyISAM表无法处理事务，这就意味着有事务处理需求的表，不能使用MyISAM存储引擎。MyISAM存储引擎特别适合在以下几种情况下使用：</p><p>1.选择密集型的表。MyISAM存储引擎在筛选大量数据时非常迅速，这是它最突出的优点。
2.插入密集型的表。MyISAM的并发插入特性允许同时选择和插入数据。例如：MyISAM存储引擎很适合管理邮件或Web服务器日志数据。</p>

1.特性

　　不支持事务：MyISAM存储引擎不支持事务，所以对事务有要求的业务场景不能使用

　　表级锁定：其锁定机制是表级索引，这虽然可以让锁定的实现成本很小但是也同时大大降低了其并发性能

　　读写互相阻塞：不仅会在写入的时候阻塞读取，MyISAM还会在读取的时候阻塞写入，但读本身并不会阻塞另外的读

　　只会缓存索引：MyISAM可以通过key_buffer缓存以大大提高访问性能减少磁盘IO，但是这个缓存区只会缓存索引，而不会缓存数据

2.适用场景

　　不需要事务支持(不支持)

　　并发相对较低(锁定机制问题)

　　数据修改相对较少(阻塞问题)

　　以读为主

　　数据一致性要求不是非常高

3.最佳实践

　　尽量索引(缓存机制)

　　调整读写优先级，根据实际需求确保重要操作更优先

　　启用延迟插入改善大批量写入性能

　　尽量顺序操作让insert数据都写入到尾部，减少阻塞

　　分解大的操作，降低单个操作的阻塞时间

　　降低并发数，某些高并发场景通过应用来进行排队机制

　　对于相对静态的数据，充分利用Query Cache可以极大的提高访问效率

　　MyISAM的Count只有在全表扫描的时候特别高效，带有其他条件的count都需要进行实际的数据访问

InnoDB

<p>InnoDB是一个健壮的事务型存储引擎，这种存储引擎已经被很多互联网公司使用，为用户操作非常大的数据存储提供了一个强大的解决方案。我的电脑上安装的MySQL 5.6.13版，InnoDB就是作为默认的存储引擎。InnoDB还引入了行级锁定和外键约束，在以下场合下，使用InnoDB是最理想的选择：</p><p>1.更新密集的表。InnoDB存储引擎特别适合处理多重并发的更新请求。
2.事务。InnoDB存储引擎是支持事务的标准MySQL存储引擎。
3.自动灾难恢复。与其它存储引擎不同，InnoDB表能够自动从灾难中恢复。
4.外键约束。MySQL支持外键的存储引擎只有InnoDB。
5.支持自动增加列AUTO_INCREMENT属性。</p><p>一般来说，如果需要事务支持，并且有较高的并发读取频率，InnoDB是不错的选择。</p>

 1.特性

　　具有较好的事务支持：支持4个事务隔离级别，支持多版本读

　　行级锁定：通过索引实现，全表扫描仍然会是表锁，注意间隙锁的影响

　　读写阻塞与事务隔离级别相关

　　具有非常高效的缓存特性：能缓存索引，也能缓存数据

　　整个表和主键以Cluster方式存储，组成一颗平衡树

　　所有Secondary Index都会保存主键信息

2.适用场景

　　需要事务支持(具有较好的事务特性)

　　行级锁定对高并发有很好的适应能力，但需要确保查询是通过索引完成

　　数据更新较为频繁的场景

　　数据一致性要求较高

　　硬件设备内存较大，可以利用InnoDB较好的缓存能力来提高内存利用率，尽可能减少磁盘 IO

3.最佳实践

　　主键尽可能小，避免给Secondary index带来过大的空间负担

　　避免全表扫描，因为会使用表锁

　　尽可能缓存所有的索引和数据，提高响应速度

　　在大批量小插入的时候，尽量自己控制事务而不要使用autocommit自动提交

　　合理设置innodb_flush_log_at_trx_commit参数值，不要过度追求安全性

　　避免主键更新，因为这会带来大量的数据移动