高性能mysql 之 抉择存储引擎(一)
高性能mysql 之 选择存储引擎(一)
1 没有特殊情况，应尽可能使用InnoDB存储引擎。
原因：InnoDB 和 MYIsAM 是mysql 最常用、使用最普遍的存储引擎。其中InnoDB是最重要、最广泛的存储引擎。她
被设计用来处理大量的短期事务。短期事务大部分情况下是正常提交的，很少有回滚的情况。InnoDB的性能和自动崩溃
恢复特性使得她在非事务型存储的需求中也非常流行，除非有非常特别的原因需要使用其他的存储引擎，否则应该优先使用InnoDB
引擎。
oracle 投入了大量资源，使得InnoDB引擎的性能得到了质的飞跃，不仅在单核，现在已经扩展到24、32甚至更多核的
系统中也表现良好。
InnoDB 采用MVCC来支持高并发，并且实现了四个标准的隔离级别，其默认级别是可重复读。并且通过间隙锁防止幻读的出现。
InnoDB 采用聚簇索引，对于主键查询有很高的性能。不过他的二级索引必须包含主键列，因此主键列应当尽可能的小。
InnoDB 内部做了很多优化，包括从磁盘读取数据是采用的可预测性预读，能够自动在内存中创建hash索引以加速度操作的自适应哈希
以及能够加速插入操作的插入缓冲区等。
InnoDB 支持热备份。
同样广泛使用的是 MyISAM存储引擎，MyISAM不支持事务，没有修复和崩溃恢复能力，需要手工操作
MyISAM 对整张表加锁 而不是针对行，读取时会对需要读到的所有表加共享锁，写入时则对表加排他锁。
2 如何选择存储引擎
一般情况下，InnoDB都是正确的选择，除非需要用到某些InnoDB不具备的特性，并且没有其他办法可以替代，
否则都应该优先选择InnoDB引擎。当然，如果不需要用到InnoDB的特性，同时其他引擎的特性能够更好地满足需求，
也可以考虑其他存储引擎。举个例子，如果不在乎可扩展能力和并发能力，也不在乎数据丢失问题，
却对InnoDB的空间占用过多比较敏感，这种场合下选择MyISAM就比较合适。
除非万不得已，否则不建议使用多种存储引擎，否则可能带来一系列复杂的问题以及一些潜在的bug和边界问题。
存储引擎层和服务器层的交互已经比较复杂，更不用说混合多个存储引擎了。
如果应用真的非常需要不同的存储引擎，请先开率以下几个因素
1 事务
2 备份
不要轻易相信 MyISAM 比 InnoDB 快的经验之谈，在很多已知的场景中，InnoDB的速度都可以让MyISAM望尘莫及
尤其是聚簇索引或者需要访问的数据都可以放入内存中的应用。
MyISAM 引擎在一开始可能没有任何问题，但随着应用压力的上升，则可能迅速恶化，各种锁争用、崩溃后的数据丢失等问题都会随之而来。
使用InnoDB 需要尽量避免select count(*) 此类的语句， 尤其是当数据规模不断增大的时候。
mysql 单台服务器的数据量 一般保持在3-5T，10T以上就可能需要建立数据仓库，infobright 是mysql 数据仓库最成功的解决方案。也有一些大数据仓库不适合
infobright ,却适合TokuDB.
1 没有特殊情况，应尽可能使用InnoDB存储引擎。
原因：InnoDB 和 MYIsAM 是mysql 最常用、使用最普遍的存储引擎。其中InnoDB是最重要、最广泛的存储引擎。她
被设计用来处理大量的短期事务。短期事务大部分情况下是正常提交的，很少有回滚的情况。InnoDB的性能和自动崩溃
恢复特性使得她在非事务型存储的需求中也非常流行，除非有非常特别的原因需要使用其他的存储引擎，否则应该优先使用InnoDB
引擎。
oracle 投入了大量资源，使得InnoDB引擎的性能得到了质的飞跃，不仅在单核，现在已经扩展到24、32甚至更多核的
系统中也表现良好。
InnoDB 采用MVCC来支持高并发，并且实现了四个标准的隔离级别，其默认级别是可重复读。并且通过间隙锁防止幻读的出现。
InnoDB 采用聚簇索引，对于主键查询有很高的性能。不过他的二级索引必须包含主键列，因此主键列应当尽可能的小。
InnoDB 内部做了很多优化，包括从磁盘读取数据是采用的可预测性预读，能够自动在内存中创建hash索引以加速度操作的自适应哈希
以及能够加速插入操作的插入缓冲区等。
InnoDB 支持热备份。
同样广泛使用的是 MyISAM存储引擎，MyISAM不支持事务，没有修复和崩溃恢复能力，需要手工操作
MyISAM 对整张表加锁 而不是针对行，读取时会对需要读到的所有表加共享锁，写入时则对表加排他锁。
2 如何选择存储引擎
一般情况下，InnoDB都是正确的选择，除非需要用到某些InnoDB不具备的特性，并且没有其他办法可以替代，
否则都应该优先选择InnoDB引擎。当然，如果不需要用到InnoDB的特性，同时其他引擎的特性能够更好地满足需求，
也可以考虑其他存储引擎。举个例子，如果不在乎可扩展能力和并发能力，也不在乎数据丢失问题，
却对InnoDB的空间占用过多比较敏感，这种场合下选择MyISAM就比较合适。
除非万不得已，否则不建议使用多种存储引擎，否则可能带来一系列复杂的问题以及一些潜在的bug和边界问题。
存储引擎层和服务器层的交互已经比较复杂，更不用说混合多个存储引擎了。
如果应用真的非常需要不同的存储引擎，请先开率以下几个因素
1 事务
2 备份
不要轻易相信 MyISAM 比 InnoDB 快的经验之谈，在很多已知的场景中，InnoDB的速度都可以让MyISAM望尘莫及
尤其是聚簇索引或者需要访问的数据都可以放入内存中的应用。
MyISAM 引擎在一开始可能没有任何问题，但随着应用压力的上升，则可能迅速恶化，各种锁争用、崩溃后的数据丢失等问题都会随之而来。
使用InnoDB 需要尽量避免select count(*) 此类的语句， 尤其是当数据规模不断增大的时候。
mysql 单台服务器的数据量 一般保持在3-5T，10T以上就可能需要建立数据仓库，infobright 是mysql 数据仓库最成功的解决方案。也有一些大数据仓库不适合
infobright ,却适合TokuDB.