MySQL 的各存储引擎特色-MySQ 存储引擎选择



前言

MySQL 的存储引擎多是全部关系型数据库产品中最具备特点的了，不只能够同时使用多种存储引擎，并且每种存储引擎和MySQL之间使用插件方式这种很是松的耦合关系。

因为各存储引擎功能特性差别较大，这篇文章主要是介绍如何来选择合适的存储引擎来应对不一样的业务场景。

 

MyISAM

1.特性

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

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

　　读写互相阻塞：不只会在写入的时候阻塞读取，MyISAM还会在读取的时候阻塞写入，但读自己并不会阻塞另外的读

　　只会缓存索引：MyISAM能够经过key_buffer缓存以大大提升访问性能减小磁盘IO，可是这个缓存区只会缓存索引，而不会缓存数据

2.适用场景

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

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

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

　　以读为主

　　数据一致性要求不是很是高

3.最佳实践

　　尽可能索引(缓存机制)

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

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

　　尽可能顺序操做让insert数据都写入到尾部，减小阻塞

　　分解大的操做，下降单个操做的阻塞时间

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

　　对于相对静态的数据，充分利用Query Cache能够极大的提升访问效率

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

 

InnoDB

1.特性

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

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

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

　　具备很是高效的缓存特性：能缓存索引，也能缓存数据

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

　　全部Secondary Index都会保存主键信息

2.适用场景

　　须要事务支持(具备较好的事务特性)

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

　　数据更新较为频繁的场景

　　数据一致性要求较高

　　硬件设备内存较大，能够利用InnoDB较好的缓存能力来提升内存利用率，尽量减小磁盘 IO

3.最佳实践

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

　　避免全表扫描，由于会使用表锁

　　尽量缓存全部的索引和数据，提升响应速度

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

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

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

 

NDBCluster

1.特性

　　分布式：分布式存储引擎，能够由多个NDBCluster存储引擎组成集群分别存放总体数据的一部分

　　支持事务：和Innodb同样，支持事务

　　可与mysqld不在一台主机：能够和mysqld分开存在于独立的主机上，而后经过网络和mysqld通讯交互

　　内存需求量巨大：新版本索引以及被索引的数据必须存放在内存中，老版本全部数据和索引必须存在与内存中

2.适用场景

　　具备很是高的并发需求

　　对单个请求的响应并非很是的critical

　　查询简单，过滤条件较为固定，每次请求数据量较少，又不但愿本身进行水平Sharding

3.最佳实践

　　尽量让查询简单，避免数据的跨节点传输

　　尽量知足SQL节点的计算性能，大一点的集群SQL节点会明显多余Data节点

　　在各节点之间尽量使用万兆网络环境互联，以减小数据在网络层传输过程当中的延时

　　注：以上三个存储引擎是目前相对主流的存储引擎，还有其余相似如：Memory，Merge，CSV，Archive等存储引擎的使用场景都相对较少，这里就不一一分析了，若是有朋友感兴趣，后面再补充吧。

原文地址：http://isky000.com/database/mysql-performance-tuning-storage-engine