MySQL数据库中三种常用存储引擎的性能比较
MySQL的存储引擎可能是所有关系数据库产品的最显著的特性。不仅可以同时使用多个存储引擎，而且每个存储引擎的插件与MySQL之间的耦合关系非常松散。由于各存储引擎的功能特点不同，本文主要介绍如何选择合适的存储引擎来处理不同的业务场景。
MyISAM
特征
交易不支持：MyISAM存储引擎不支持事务，所以业务场景所需的交易不能使用
表级锁定：它的锁机制是一个表级索引，它可以使锁实现成本小，但也大大降低了它的并发性能。
读写对方拦网：不仅阻塞读写的时候，MyISAM也会阻止同时读写，但阅读本身不会阻止其他阅读。
它只缓存索引：MyISAM可以提高访问性能和key_buffer缓存减少磁盘IO，但是这个缓存只缓存索引而不是缓存数据。
适用场景
不需要事务支持（不支持）
相对较低的并发性（锁机制问题）
数据修改相对较小（阻塞问题）
主要通过阅读来阅读
数据一致性要求不是很高。
最佳实践
尽可能多地索引（缓存机制）
调整读写优先级以确保基于实际需求的重要操作更为优先
启用延迟插入以提高质量写性能
尽可能将插入数据写入尾部，减少阻塞。
分解大型操作以减少单个操作的阻塞时间。
减少并发性，一些高并发场景通过应用程序排队。
对于相对静态的数据，充分利用查询缓存可以大大提高访问效率。
MyISAM算是高度有效的只有当全表扫描，并与其他条件计数需要访问实际数据
InnoDB
特征
良好的事务支持：支持4个事务隔离级别，支持多版本读取
行级锁定：通过索引实现，全表扫描仍将是表锁，注意间隙锁的影响
读写阻塞与事务隔离级别有关。
高效的缓存特性：缓存索引和缓存数据
整个表和主键以集群的方式存储，形成一个平衡树。
所有次要索引都将保存主键信息。
适用场景
需要事务支持（具有更好的事务特性）
行级锁对高并发性有很好的适应性，但必须保证索引完成查询。
频繁更新数据的场景
对数据一致性的高要求
硬件设备有一个大的内存，可以使用InnoDB的缓存来提高内存的利用率和减少磁盘IO的尽可能多的能力
最佳实践
主键尽可能小，以避免对次级索引造成很大的空间负担。
避免使用全表扫描，因为使用表锁。
尽可能地缓存所有索引和数据，以提高响应速度。
努力控制自己的交易小批量插入尽可能多，而不是使用自动提交提交自动
innodb_flush_log_at_trx_commit参数设置合理，不过分追求安全
避免主键更新，因为这会带来大量数据移动。
ndbcluster
特征
分布：分布式存储引擎，可以由几个ndbcluster存储引擎存储整个数据部分。
支持事务：如InnoDB，支持交易
不能在主机与mysqld：可以从一个单独的主机参数分离，然后通过网络沟通和mysqld
内存需求很大：新版本索引和索引数据必须存储在内存中。所有数据和索引的旧版本必须存在于内存中。
适用场景
具有很高的并发要求
对单个请求的响应不是很关键。
查询简单，过滤条件是相对固定的，数据量少，和切分的水平是不需要的。
最佳实践
尽量简化查询，避免跨节点传输数据。
尽可能地满足SQL节点的计算性能，较大的SQL节点集群显然是冗余的数据节点。
为了减少网络层中数据传输的延迟，在节点之间尽可能多地使用网络环境。
注意：上述三种存储引擎是相对主流的存储引擎，相对较少的其他存储引擎，如内存、合并、CSV和存档。