mysql存储引擎的选择

实例

数据记录

　　假设,对于来自中心电话交换机的所有电话呼叫,都是要使用mysql进行实时的数据记录(Logging),或者,APache中已经安装了mode_log_sql模块,可以将web站点的所有访问信息直接记录到表中,那么这类应用中,熟读了能是最重要的设计指标,没人希望数据库因此陷入瓶颈状态,myisam引擎和Archive引擎非常适合这类应用,因为他们消耗的系统开销很小,并且支持每秒钟高达数千记录的插入,另外,PBXT存储引擎可能也很适合这种数据记录应用,

　事情开起来可能很简单,如果还要运行查询汇总这些数据的操作这就有问题了 ,严重减缓的数据的插入操作

　一种使用mysql的复制特性,把数据复制到另一个服务器上面去,执行那些对cpu和资源要求苛刻的程序,这可以将主服务器腾出来,继续完成插入此操作,同事也不用担心,实时数据的记录

　当然也可以选择在低负载的时候进行查询,不过随着应用的增长这不是一个很好地选择

　另一种选择就是合并表,调整应用,不是将所有的记录都存在一张表中,而是将数据记录到不同的表中,表可以根据年份,月份,源表名来规定,例如Web_logs_2008_01或者Web_logs_jan然后定义一个合并表,用于相关的查询,合并表中存储了汇总的所有的数据,按日或周策略都是一样的,只需建立特定的表明,例如在Web_logs_2008_01的表中不需要进行写操作,运行相关的查询操作,而对于当前表可以不断实时记录数据

只读表或主读表

　　　有些表数据用于编制目录,或分列清单(如工作岗位,竞拍物品,不动产等),在这些表上的读操作远比写操作多,对于这类表,加入不介意myisam的崩溃问题,那么选择myisam是很合适的,不过不要 低估崩溃的问题的重要性,许多用户根本不了解那些不确保一定能把数据写入磁盘的 的风险,(可以模拟,在测试服务器上模拟真实的负载,运行应用,并真的拔下电源,对于从崩溃中的数据,第一手的资料是无价的)

　　　不要轻易相信myisam比innodb之类快的说法,这并不完全正确,在很多环境下,innodb都远远快于myisam,特别是 使用聚集索引,或者将数据装入内存中的应用,

订单处理

　　如果涉及任何订单处理,事物操作一般是必不可少的,另一个问题是引擎是否要支持外键约束,这可能innodb是最佳的选择

　

股票报价

　　　如果股票报价信息用于分析,那么myisam是非常实用 的,当然选择这种引擎的注意事项也是一样的不过,如果要支持一个高流量的web服务,提供实时的报价,并服务数千在线用户,那么查询是绝对不能容忍等待的,大量的客户可能需要同时读/写通常的解决方法是行级索,或者在方案设计中减少更新操作的处理

电子公告板和主题讨论论坛

　　　对于mysql用户,主题讨论论坛,应用是一个很有趣的问题,目前有数百个基于PHP或者Perl的免费用,支持主题讨论的功能,其中大多数应用在处理数据库中操作效率不高,比如他们常常为了每一个请求,要执行一堆的查询,其中有些应用是’非数据库相关’的,过意他们的查询不能利用发挥任何一种数据库的长处,另外这类应用还要常常更新计数器,或者为各种主题讨论计算访问统计信息,很多这样的应用只使用的几个表来存储所有数据,因此几个核心的表就会变成读写负载非常重,写操作也很频繁的表,另外为了保持数据库的一致性,被迫使用枷锁的机制,也成为征用现象的一个重要源头

　　　尽管有这些设计的缺陷,大多数这类应用在低负载的情况下,还是可以良好的工作的,不过,如果web站点的规模迅速增长,流量增加巨大,那么应用可能会因此变得非常慢,一种典型的解决方案,是换一种可以处理高负载的读/写存储引擎,不过,如果用户这么做,有时可能惊讶的发现,应用系统比原来更慢了

　　　>select count(*) from table;

　　问题是,不是所有引擎都能很快运行这类查询,myisam可以,其他的恐怕不行,对于所有亲情来说,都有类似的例子,

CD-ROM应用

　　　如果要发布一个机遇CD-ROM或DVD-ROM,并且使用mysql数据文件的应用,可以考虑使用myisam表或压缩的myisam表,这些表容易彼此隔离,并且支持在不同的介质上相互拷贝,比起压缩的 表,压缩的myisam表只占用很少的存储空间但其数据只能是只读的,对于某些应用,这可能是一个问题,但对于那些数据总放在只读介质上的应用来书没有理由不选择使用压缩表