MySQL之架构设计与历史
第三方存储引擎
MySQL从2007年开始提供了插件式的存储引擎API,从此用处了一系列为不同目的而设计的存储引擎。其中有一些已经合并到MySQL服务器，但大多数还是第三方产品或者开源项目。
OLTP类引擎
Percona的XtraDB存储疫情是基于InnoDB引擎的一个改进版本，已经包含在Percona Server和MariaDB中，它的改进点主要集中在性能、可测量性和操作灵活性方面。XtraDB可以作为InnoDB的一个完全的替代产品，甚至可以兼容地读写InnoDB地数据文件，并支持InnoDB的所有查询。
另外还有一些和InnoDB地一个完全地替代产品，比如都支持ACID事务和MVCC。其中一个就是PBXT,由Paul McCullagh 和Primebase GMBH开发。它支持引擎级别的复制、外键约束，并且以一种比较复杂的架构对固态存储(SSD)提供了适当的支持，还对较大的值类型如BLOB也做了优化。PBXT是一款社区支持的存储引擎，MariaDB包含了该引擎。
TokuDB引擎使用了一种新的叫作分形树(Fractal Trees)的索引数据结构。该结构是缓存无关的，因此即使其大小超过内存性能也不会下降，也就没有内存生命周期和碎片的问题。TokuDB是一种大数据(Big Data)存储引擎，因为其拥有很高的压缩比，可以在很大的数据量上创建大量索引。目前其最适合在需要大量插入数据的分析型数据集的场景中使用。
RRethinkDB最初是为固态存储(SSD)而设计的，然而随者时间的推移，目前看起来和最初的目标有一定的差距。该引擎比较特币的地方在于采用了一种只能追加的写时复制B树(append-only copyon-write B-Tree)作为索引的数据结构。
在Sum收购MySQL AB后，Falcon存储引擎曾经作为下一代存储引擎被寄予期望，但现在该项目已经被取消很久了
面向列的存储引擎
MySQL默认是面向行的，每一行的数据是一起存储的，服务器的查询也是以行为单位处理的。而在大数据量处理时，面向列的方式可能效率更高。如果不需要整行的数据，面向列的方式可以传输更少的数据。如果每一列都单独存储，那么压缩的效率也会更高。
Infobright是最有名的面向列的存储引擎，在非常大的数据量(数十TB)时，该引擎工作良好。Infobright是为数据分析和数据仓库应用设计的。数据高度压缩，按照块进行排序，每个块都对应一组元数据。在处理查询时，访问元数据可决定跳过该块，甚至可能只需要元数据即可满足查询的需求。但该引擎不支持索引，不过在这么大的数据量级，即使有索引也很难发挥作用，而且块结构也是一种准索引(quasi-index).Infobright需要对MySQL服务器做定制，因为一些地方需要修改以适应面向列存储的需要。如果查询无法在存储层使用面向列的模式执行，则需要在服务器层转换成按行处理，这个过程会很慢，Infobright有社区版和商业版两个版本。
另外一个面向列的存储引擎时Calpont公司的InfiniDB，也有社区版和商业版。InfiniDB可以在一组机器集群间作分布式查询。
社区存储引擎
如果要列举社区提供的所有存储引擎，可能会有两位数，甚至三位数。但是负责地说，其中大部分影响力有限，很多可能都没有听说过，或者只有极少人在使用。在这里列举了一些，也大都没有在生产环境中应用过，慎用，后果字符。
- 1.Aria.
之前地名字是Maria,是MySQL创建者计划用来替代MyISAM的一款引擎。MariaDB包含了该引擎，之前计划开发的很多特性，有些因为在MariaDB服务器层实现，所以引擎层就取消了。可以说Aria就是解决了崩溃安全恢复问题的MyISAM，当然也还有一些特性是MyISAM不具备的，比如数据的缓存(MyISAM只能缓存索引) - 2.Groonga.
这是一款全文索引引擎，号称可以提供准备准确而高效的全文索引 - 3.OQGraph
该引擎由Open Query研发，支持图操作(比如查找两点之间的最短路径)，用SQL很难实现该类操作 - 4.Q4M
该引擎在MySQL内部实现了队列操作，而用SQL很难在一个语句实现这类队列操作 - 5.SphinxSE.
该引擎为Sphinx全文索引搜索服务器提供了SQL结构 - 6.Spider
该引擎可以将数据切分成不同的分区，比较高效透明地实现了分片(shard)，并且可以针对分片执行并行查询(分片可以分布在不同的服务器上) - 7.VPForMySQL.
该引擎支持垂直分区，通过一系列的代理存储引擎实现。垂直分区指的是可以将表分成不同列的组合，并且单独存储。但对查询来说，看到的还是一张表，该引擎和Spider的作者是同一人
选择合适的引擎
这么多存储引擎，我们怎么选择?大部分情况下，InnoDB都是正确的选择，所以Oracle在MySQL5.5版本时终于将InnoDB作为默认的存储引擎了。对于如何选择存储引擎，可以简单概括为一句话"除非需要用到某些InnoDB不具备的特性，并且没有其他办法可以替代，否则都应该优先选择InnoDB引擎"。例如，如果要用到全文索引，建议优先考虑InnoDB加上Sphinx的组合，而不是使用支持全文索引的MyISAM。当然如果不需要用到InnoDB的特性，同时其他引擎的特性能够更好地满足需求，也可以考虑一下其他存储引擎。举个例子，如果不在乎可扩展能力和并发能力，也不在乎崩溃后的数据丢失问题，却对InnoDB的空间占用过多比较敏感，这种场合下选择MyISAM就比较合适。
除非万不得已，否则建议不要混合使用多种存储引擎，否则可能带来的一系列复杂的问题已经一些潜在的buf和边界问题。存储引擎层和服务器层的交互已经比较复杂，更不用说混合多个存储引擎了。至少，混合存储对一致性备份和服务器参数配置都带来了一些困难。
如果应用需要不同的存储疫情，请先考虑一下几个因素。
- 1.事务
如果应用需要事务支持，那么InnoDB(或者XtraDB)是目前最稳定并且经过验证的选择。如果不需要事务，并且主要是SELECT和INSERT操作，那么MyISAM是不同的选择。一般日志行的应用比较符合这一特性。 - 2.备份
备份的需求也会影响存储引擎的选择。如果可以定期地关闭服务器来执行备份，那么备份的因素可以忽略。反之，如果需要在线热备份，那么选择InnoDB就是基本的要求 - 3.崩溃恢复。
数据量比较大的时候，系统崩溃后如何快速地恢复是一个需要考虑地问题。相对而言，MyISAM崩溃后发生损坏地概率比InnoDB要高很多，而且恢复速度也要慢。因此，即使不需要事务支持，很多人也选择InnoDB引擎，这是一个非常重要的因素。 - 4.特有的特性.
最后，有些应用可能一来一些存储引擎所独有的特性或者优化，比如很多应用一来聚簇索引的优化。另外，MySQL中也只有MyISAM支持地理空间搜索。如果一个存储引擎拥有一些关键的特性，同时却又缺乏一些必要的特性，那么有时候不得不做折中的考虑，或者在架构设计上做一些取舍。某些存储引擎无法直接支持的特性，有时候通过变通也可以满足需求。
如果不了解具体的应用，上面提到的这些概念都是比较抽象的。所以接下来会讨论一些常见的应用场景，在这些场景中会涉及很多的表，以及这些表如何选用合适的存储引擎。
常见的引擎应用场景
- 1.日志型应用
假设你需要实时地记录一台中心电话交换机的每一通电话的日志到MySQL中，或者通过Apache的mod_log_sql模块将网站的所有访问信息直接记录到表中。这一类应用的插入速度有很高的要求，数据库不能称为瓶颈.MyISAM或者Archive存储引擎对这类应用比较合适，因为它们开销低，而且插入速度非常快。
如果需要对记录的日志做分析报表，那么事情就会变得有趣了。生成报表的SQL很有可能会导致插入效率明显降低，这时候该怎么办呢？
一种解决办法，是利用MySQL内置的复制方案将数据复制一份到悲苦，然后在备库上执行比较消耗时间和CPU的查询。这样主库只用于高效的插入工作。而备库上执行的查询也无须担心影响到日志的插入性能。当然也可以在系统负载较低的时候执行报表查询操作，但应用在不断变化，如果依赖这个策略可能以后会导致问题。
另外一种办法，在日志记录表的名字中包含年和月的信息，比如web_logs_2012_01或者web_logs_2012_jan.这样可以在已经没有插入操作的历史表上做频繁的查询操作，而不会干扰到最新的当前表上的插入操作 - 2.只读或者大部分情况下只读的表。
有些表的数据用于编制类目或者分列清单(如工作岗位、竞拍、不动产等)，折中应用场景是典型的读多写少的业务。如果不介意MyISAM的崩溃恢复问题，选用MyISAM引擎是合适的。不过不要低估崩溃恢复问题的重要性，有些存储引擎不会保证将数据安全地写入到磁盘中，而许多用户实际上并不清楚这样有多大的风险(MyISAM只将数据写到内存中，然后等待操作系统定期地将数据刷出到磁盘上)
一个值得推荐的方式，是在性能测试环境模拟真实的环境，芸一行应用，然后拔下电源模拟崩溃测试。对崩溃恢复的第一手测试经验是无价之宝，可以避免真的碰到崩溃时手足无措
不要轻信"MyISAM比InnoDB快"之类的经验之谈，这个结论往往不是绝对的。在很多我们已知的场景中，InnoDB的速度都可以让MyISAM望尘莫及，尤其是使用到聚簇索引，或者需要访问到数据都可以放入内存的应用。当设计上述类型的应用时，建议采用InnoDB。MyISAM引擎在一开始可能没有任何问题，但随者应用压力的上升，则可能迅速恶化。各种锁争用、崩溃后的数据丢失等问题都会随之而来。 - 3.订单处理
如果涉及订单处理，那么支持事务就是必要选项。半完成的订单是无法用来吸引用户的。另外一个重要的考虑点是存储引擎对外键的支持情况，InnoDB是订单处理类应用的最佳选择 - 4.电子公告牌和主题讨论论坛。
对于MySQL用户，主题讨论是个很有意思的话题。当前有成百上千的基于PHP或者Perl的免费系统可以支持主题讨论。其中大部分的数据库操作效率都不高，因为它们大多倾向于在一次请求中执行尽可能多的查询语句。另外还有部分系统设计为不采用数据库，当然也就无法利用到数据库提供的一些方便的特性。主题讨论区一般都有更新计数器，并且会为各个主题计算访问统计信息。多数应用只设计了几张表来保存所有的数据，所以核心表的读写压力可能非常大。为保证这些核心表的数据一致性，锁称为资源争用的主要因素。
尽管有这些设计缺陷，但大多数应用在中低负载时可以工作得很好。如果Web站点得规模迅速扩展，流量随之猛增，则数据库访问可能变得非常慢。此时一个典型得解决方案是更改为支持更高读写得存储引擎，但有时用户会发现这么做反而导致系统变得更慢了。用户可能没有意识到这是由于某些特殊查询得缘故，典型的如:
mysql> SELECT COUNT(*) FROM table;
问题就在于，不是所有的存储引擎运行上述查询都非常快:对于MyISAM确实会很快，但其他的可能都不行。每种存储引擎都能找出类似的对自己有利的例子
- 5.CD-ROM应用
如果要发布一个基于CD-ROM或者DVD-ROM并且使用MySQL数据文件的应用，可以考虑使用MyISAM表或者MyISAM压缩表，这样表之间可以隔离并且可以在不同介质上相互拷贝。MyISAM压缩表比未压缩的表要节约很多空间，但压缩表是只读的。在某些应用中这可能是个大问题。但如果数据放到只读介质的场景下，压缩表的只读特性就不是问题，就没有理由不采用压缩表了。 - 6.大数据量
什么样的数据量算大？我们创建或者管理的很多InnoDB数据库的数据量在3~5TB之间，或者更大，这是单台机器上的两，不是一个分片(shard)的量。这些系统运行得还不错，要做到这一点需要合理地选择硬件，做好物理设计，并未服务器地IO瓶颈做好规划。在这样的数据量下，如果采用MyISAM，崩溃后的恢复就是一个噩梦。
如果数据量继续增长到10TB以上的级别，可能就需要建立数据仓库。Infobright是MySQL数据仓库最成功的解决方案，也有一些大数据库不适合Infobright，却可能适合TokuDB
