MySQL架构 - MySQL存储引擎 -实践的例子

Ericky

如果没有一些实际的例子，上节所说的选择存储引擎可能很空洞。来让我们看下一普通的应用程序。接下来我们会看到各种各样的表以及选择哪个引擎适合它们。下一节会做个存储引擎的总结。
Logging(日志)
假如你想用MySQL实时记录电话交换机中每个电话的通话记录。还有你在APACHE安装了mod_log_sql，可以把每次访问网站的记录直接写入到表中。像这种应用，速度是最终的目标。你不想数据库作为瓶颈。MyISAM和Archive存储引擎都可以选择，因为它们消耗低以及每秒可以插入上千的记录。PBXT引擎也适合这种日志的系统。
然而，如果你决定汇总日志出报表，事情就变得有趣多了。这需要依靠查询语句了，但为了生成报表大量的收集数据会降低写入数据的错误。这样的话，应该怎么做呢？
一个解决方案是使用MySQL内部的复制特性把数据复制到第二个（子服务器）服务器上。然后把消耗时间和CPU的操作都放到这个服务器上。这就使主服务器自由的插入数据，运行查询在子服务器上，而不用担心影响实时的日志。
你也可以在低负载的时候查询数据，但是随着应用的使用越来越多，这种策略就变得不可靠了。
另一个解决方案是使用Merge表。调整程序去记录到很多表中，如web_logs_2008_01或者web_logs_2008_jan，而不是存储在一张表中。之后可以定义你想统计数据的表了。如果你想按日或者月来统计。这个策略可以使用。你仅仅是创建更多的表。如web_logs_2008_01_01。这样你查询的表是汇总表，并不会被写入了。你的应用就可以不间断的插入它自己的当前表。
只读或者经常读取的表
一些表包含的数据常用来构成一个分类或者一些排序的列表，这些数据读取的频率要高于写入的频率。如果不考虑MyISAM崩溃的情况，它还是个比较好的选择。千万不要低估崩溃的重要性。一些用户还没有明白使用一个连已写入硬盘的数据都读取不了的引擎有多么的危险。
不要相信MyISAM要比InnoDB快这些流言。这并不是绝对的正确。我们可以找出许多情形可以让InnoDB把MyISAM扔进垃圾桶。尤其针对那些集群索引和数据缓存的应用。读完了整本书，你就会明白影响存储引擎性能的因素（数据大小，I/O操作次数，主键相对的辅助索引）以及哪些对你的应用比较重要。
订单流程
当你处理任意种类的订单流程。事物处理是必须的。完成一半的订单，不会让你的客户喜欢你的服务。还有要考虑的就是引擎是否需要支持外键约束。目前为止，虽然有许多事物的引擎可以选择，但InnoDB看起来是最佳的引擎来处理这种订单式应用。
实时股票行情
如果你收集实时股票行情来做自己的分析。MyISAM可以很好的工作，然而，如果你运行的是高访问量的web service，这个服务为上千人提供了实时的股票报价。那么不应该去等待一个查询。许多客户端会同时读和写数据，因此行锁或者设计为最小化更新才是解决之道了。

公告栏和论坛
论坛对于MySQL用户是非常有趣的问题。现在已经有上百个免费的PHP和PERL的论坛了。它们之中有很多并没有有效地使用数据库。因此往往每个请求都要执行很多的语句。一般来说其中的一些语句都是独立于数据库的，因此那些语句都没有利用任意数据库的一些好的特性。他们也对于不同的论坛更新计数器和手机有用的统计信息。许多系统也常常使用一些单片表（monolithic table:译者注：我理解为一张表存放着太多不相干的字段，这张表就叫做monolithic table。可以把这张表分为不同的几张表。）来存储所有的数据。结果就是一些核心表变得频繁的读写。以及锁为了保持数据的一致性，而产生了大量的竞争。
除了设计的缺陷，大部分系统只能在中小的压力下很好的工作。然而如果网站足够的大了以及有了很大的流量。它就会变的很慢。
显而易见的解决方案是选择不同的存储引擎来处理频繁的读写。但是用户会发现系统比以前还更慢了。
用户没有发现系统使用了一些特殊的查询，像如下语句
select count(*) from table;
问题在于并不是所有的搜索引擎可以快速的执行它。MyISAM可以做到，但是其他的引擎可能做不到了。对于每个引擎都有相似的例子。下一章我们帮助你如何避免让你惊讶的事情发生以及教你怎样发现和解决这些问题。
CD-ROM的应用程序
如果你发布过使用MySQL数据文件的CD-ROM活着DVD-ROM的应用，考虑使用MyISAM或者压缩的MyISAM表。这样就非常容易保持表的独立，可以把它复制到其他的媒介中。压缩的MyISAM表比未压缩的表节省了不少空间。但是压缩的表是仅仅只读的。对于一些应用可能会有一定的问题，但是因为数据存放在只读的媒介中，对于这种特殊的情况，就没有理由不适用压缩的表了。