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

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，这个服务为上千人提供了实时的股票报价。那么不应该去等待一个查询。许多客户端会同时读和写数据，因此行锁或者设计为最小化更新才是解决之道了。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!