mysql存储引擎的选择

mysql作为一款免费开源的数据库，使用热度一直居高不下。下面分析一下mysql架构及对于mysql存储引擎的选择。

mysql逻辑架构

第一层

客户端链接，这个在很多数据库上都是相同的逻辑，不做过多的赘述。

第二层

是mysql比较有意思的部分。大部分mysql的核心服务功能都在这一层，包括查询解析，分析，优化，缓存以及所有的内置函数，例如日期，时间，数字加等。所有跨存储引擎的功能都在这一层实现：存储过程，触发器，视图等。

第三层

存储引擎，存储引擎主要负责mysql中数据的存储和提取。mysql服务器通过API的方式与存储引擎进行通信，这种API的方式巧妙的解决了不同引擎直接的差异，使得差异对上层服务器透明。mysql才有插拔式存储引擎，可以自己选择适合的存储引擎，不同的表可以使用不同的存储引擎，不同的存储引擎之间不会相互通信，只是相应上层的调用请求。

常见的引擎

InnoDB存储引擎

是mysql默认的事务型引擎，也是最重要、使用最广泛的存储引擎。InnoDB的性能和自动崩溃恢复的特性是他备受青睐的主要原因。性能是基于他采用的聚簇索引。并且支持行级锁，提高了并发性能。

MyISAM存储引擎

在mysql5.1及之前的版本是是默认的存储引擎。提供了大量的特性，包含全文索引，压缩，空间函数等，但是不支持事物和行级锁（采用表级锁）。还有一个致命的缺陷就是崩溃后无法安全恢复（采用数据先存储在系统内存，定期刷新到磁盘，宕机是未刷入磁盘的数据将丢失）

Memory存储引擎

将数据存储到内存中，读写效率都非常高，但是由于不能持久化的原因非特定场景一般不适用。

Archive存储引擎

缓存所有的写并利用zlib对插入行进行压缩，所以比MyISAM表的磁盘I/O更少。但是每次select查询都需要执行全面扫描。

所以Archive适合日志和数据采集

 

引擎的选择

选择引擎的原则是：除非需要用到InnoDB不具备的特性，并且没有其他办法可以替代，否则应该优先选择InnoDB引擎。

例如需要用到全文索引，建议优先考虑InnoDB+Sphinx的组合，而不是适用支持全文索引的MyISAM。当然如果不在乎扩展能力和并发能力并且可以接受崩溃后的数据丢失，却对InnoDB的空间占用比较敏感（InnoDB由于对事务的优化多加了2列记录创建时间，删除时间），这种场合可以选择MyISAM。

日志型应用

如果只是为了记录日志，只对插入速度要求比较高，数据库不能成为瓶颈，那么MyISAM和Archive存储引擎比较合适，他们都是开支小，而且插入速度极快。如果需要分析日志，考虑到执行sql会明显降低插入性能，可以考虑用主备库，主库写，从库读。

只读或者大部分情况下只读

建议采用InnoDB。而MyISAM在一开始可能没任何问题，但是随着压力的上升，可能会因为各种锁争用迅速恶化，崩溃后数据丢失等问题随之而来。

订单处理

如果涉及订单，肯定是要支持事务的。还有就是对外键的支持（订单表和用户表的关联等），InnoDB是订单类应用的最佳选择。

大数据量

3-5T/每台机器  的数据量可以采用InnoDB。如果数据达到10TB以上的级别，就需要建立数据仓库了，Infobrigth是MySQL数据仓库最成功的方案。当然也有些大数据不适合Infobright，却可能适合TokuDB。

改变单个表的引擎

mysql支持单个表设置单个的存储引擎，但是不建议一个mysql服务用多个存储引擎，可能出现意想不到的问题。

将一个表从一个引擎改为另外一个引擎最简单的方法就是ALTER TABLE语句，如：alert tablemytable ENGINE=InnoDB；