MySQL是一个小型关系型数据库管理系统，开发者为瑞典MySQL AB公司。在2008年1月16号被Sun公司收购。而2009年,SUN又被Oracle收购.对于Mysql的前途,没有任何人抱乐观的态度.目前MySQL被广泛地应用在Inte.net上的中小型网站中。由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。
假如你想要用MysQL来实时记录从呼叫中心的电话来的每一个电话的日志记录。或者你可能已经为Apache安装了mod_log_sql模块，这样你就可以将网站所有的访问记录到数据库中。在这样的一个应用中，速度可能是最重要的目标，你不想要数据库成为瓶颈。MyISAM和Archive存储引擎将会是很好的选择，因为它们只有很低的开销并且可以一秒钟插入成千上万条记录。PBXT存储引擎也可能特别适合这个目的。
然而，如果你决定对已经记录的数据进行分析总结，那么事情就开始变得有趣了。根据你所使用的查询的不同，有很大的可能性因为数据采集的影响而使得整个插入过程变慢。这个时候你应该怎么办？
一个解决方案是利用MySQL的内置复制特性来将数据克隆到第二台服务器（从机）上，然后在从机上运行对于对于时间和CPU要求比较高的查询。这使得主机只是插入操作，并且可以使你在从机上运行任何你需要的查询而不必担心对日志实时性的影响。
你也可以将查询分成开销很小的查询来完成任务，但是不要指望这个策略能一直有效，因为你的程序的规模一直在增长。
另外的一个选择是使用Merge表。Merge表不会总是将日志记录到同一个表，可以通过调整应用使得日志按照需求记录到按年、月、日分表的表中去，比如web_log_2009_01或者web_log_2009_01_01。然后定义一个Merge表，它包含了你想要进行综合分析的数据。如果你需要分析一天或者一周的数据，那么这个策略可以直接使用，而你只需要创建分得更细的表，比如web_logs_2008_01_01。你的应用将日志插入到一张表中，而你而在其他的表上进行查询。
只读或者很少写的表
包含用于创建目录或者列出某类数据（如职业、标售、财产等）的表通常读要远大于写操作的次数。这使得它们成为MyISAM表的首要客户，当然前提是你不在乎当MyISAM崩溃之后的故障恢复的话。不要低估这个问题，很多用户其实对于一个不认真尝试将数据写入硬盘的存储引擎所带来的风险并不是很清楚。
注：一个很好的想法是在一台测试服务器上运行一个实际负载的模拟，然后去拨掉电源插销。从故障中恢复数据的第一手经验是无价。它可以能够轻松应对后面遇到的许多很令人头痛的问题。
不要只是单纯的相信“MyISAM比InnoDB快”的经验。它并不是无条件的正确的。我们可以举出很多InnoDB远比MyISAM快的例子，尤其是对于那些使用簇索引或者数据正好在内存中的应用来说。当你读过本书的其他部分之后，你就会对于影响存储引擎性能的因素有一个比较清楚的认识（数据量、IO率、主键vs次主键等等），这样子你才能够对哪些因素对于你的应用有影响有清楚的理解。
订单处理
当你处理不管何种类型的订单处理时，事务都是不可或缺的。半完成状态的订单不可能使你的客户喜欢你所提供的服务。另外一个很重要的因素是存储引擎是否支持外键约束。在这本书完成之时，InnoDB似乎还是你最好的选择，但是其他的事务型存储引擎也可以作为一个候选者。
股票报价
如果你正在为个人分析而收集股票报价的话，一般来说，MyISAM将会工作地很好。但是，如果你正在运行一个流量很大的web service，它有实时的报价反馈并且有成千上万的用户的话，查询不能有等待。许多客户可能同时都想往同一张表里插入数据或者读取数据，因此行级别的锁或者一种可以减少更新的策略都是可选择的解决方案。
BBS的论坛
针对主题的讨论对于MySQL的用户来说是一个很有趣的问题。有许多免费的基于PHP和Perl的系统都可以提供针对主题的讨论。其中许多应用并没有考虑数据库效率问题，因此它们一般都会对一个请求查询多次数据库。有一些应用是不针对具体数据库的，因此它们并没有使用任何数据库的特性来提升性能。它们会针对多个主题来更新计数器，收集使用统计等。有些应用甚至采用单表来存储它们所有的数据。事实上造成的结果是，少部分中心表成为读写操作的重心，而用来保证一致性的锁成为造成竞争的基本来源。
如果不考虑设计上的缺陷的话，这些系统多数都是为了中小型负载而设计的。然而，如果一个网站增长得很大，并且流量也很可观时，它很可能就会变得很慢了。一个显而易见的解决方案是换用另外一种可以处理大量读写操作的存储引擎，但是试图这么做的用户往往会惊讶地发现他们的系统甚至比没有转换之前更慢。
文章来源于领测软件测试网 https://www.ltesting.net/
