ACCESS复合承载 性能超越MYSQL

网络整理 - 09-08

由于众所周知的原因,ACCESS在大型站点应用中都靠不上边,主要问题就是数据量大了以后几乎无法索引。当ACCESS里数据过万后,明显可以感觉到速度变慢,过2万条数据后,慢的可以跟蜗牛相提并论了。但是由于某人灵光突现,想到了一个解决ACCESS数据库承载问题的方案,那个某人就是偶啦……最喜欢搞歪门邪道地偶(另有小偷程序生成器)。

这个解决方案就是“ACCESS复合承载”(本人原创的词,实在找不到合适的描述),简单说就是将原来一个数据库剥离为多个,成为一个主数据库带多个辅数据库。拿我已经实现的开良小说系统来说,小说信息都存储在主数据库内,用于列表检索,小说章节存在辅数据库内,每本小说独立占一个数据库。可能这样你看着有点模糊,我们来下数据对比,一个小说站,算5个分类,每个分类400部小说,每部小说300章节(其实很多小说都不止300章节),那么数据量为5×400×300=60万条数据,这还只是章节数据,其他的还有书目、用户、评论等等数据,这样大的数据量,即使是MYSQL或者MSSQL也要好好规划。但是,采用ACCESS复合承载以后,就会变成1个书目数据库加2000个章节数据库,每个章节数据库里有300条数据,从只有300条记录的ACCESS库里读东西,速度我想大家都能理解,即使是动态读取也绝对不慢。那么,这里又涉及到一个关键的问题,如何将主库与辅库连起来,这其实很简单,我在小说系统里用的是用书目的ID来命名数据库,将数据库打开与关闭做成一个函数,要什么小说的章节就直接打开这个小说的数据库就OK了。

谈完方法,我们来谈谈优缺点。优点很显著,其一,可以做以前很多做不了的事情,ACCESS库原来根本做不了小说系统,现在可以做了,而且还可以做的很大。其二,ACCESS是以独立文件形式存在的,可以很方便的实现复合承载,其他数据库做不到这么方便。其三,一个数据库仅几百条数据,读取效率绝不在其他数据库之下(例如MYSQL 、MSSQL)。其四,ACCESS一般的空间都支持,通用性很高,而且大小不限哦。

接着来看缺点,第一,对程序员的要求也要高一些,数据库的规划必须要完善,数据库多了后要用执行SQL语句来修改格式,不懂编程语言的人是搞不了的。第二,数据检索始终还是有缺陷(对于一些文章系统来说,小说系统压根没这缺陷),无法进行全库检索,只能单库检索。

昨天晚上到今天早上一共花了8个小时,才把系统粗略做出来,睡眠不足,脑子都有点混,写的乱七八糟(其实偶本来就不会写,找个理由挡下。。),希望各位大大不要笑偶。。如果你也有邪门歪道的想法,也可以与我联系哦。偶MAIL:[email protected],