Access优已成忧，一年后，还是离开了秋色园了

从上个月起，秋色园 QBlog 的数据库，已经从access+sqlite变更为sql2000+sqlite，从此，access离开了秋色园的怀抱。 该走的还是走了，秋色园在用Access一年多后，目前对本人来说，已优无可优，甚到为之担忧的地步，终于还是离开了。 下面让我们简单回顾一下

 

从上个月起，秋色园QBlog的数据库，已经从access+sqlite变更为sql2000+sqlite，从此，access离开了秋色园的怀抱。

 

该走的还是走了，秋色园在用Access一年多后，目前对本人来说，已优无可优，甚到为之担忧的地步，终于还是离开了。

 

下面让我们简单回顾一下秋色园与Access恩怨情仇(太久没写文章，不习惯写长文了）：

 

恩：还记得最早秋色园使用Access，是由于秋色园是寄在朋友的godaddy的虚拟子目录下，那时候还没咋认识sqlite，因此access是最优选择，access感觉还是不错的，一开始感觉速度还是挺快的。

优点：简单实用，啥也不用想，传上去就OK了。

 

怨：随着秋色园文章量的增加，access在速度上，特别是分页速度，已经明显的力不从心，文章量越大，速度越是下降的明显，多次优化分页方法，终于速度上去了一点点，但这一点点并解决不了问题，后来换上了512M内存的vps。

缺点：经不起量（几万以上）的折磨。

 

情：虽然秋色园多次尝试换其它数据库，包括在oracle、Mysql、mssql等数据库上运行过秋色园，但由于内存实在太小，最终还是回归到access上，虽然也一度在sqlite上运行了，但没发sqlite有啥速度改善，于是一切回到了access，为并之优化打算奋斗到底。

优点：原来还好很多可优化的地方。

 

每次优化完access的问题，总多少会感觉到点优越感，弄久了，似觉的感情深了，以下回忆一下和Access优化有关的都有什么来着：

1：优化分页语句：在组合sql语句时，可以进行sql语句优化，这个好像到处都通用的，不需要分access了。
 
2：数据库分库：其实就是链接表，用链接表，的解可以在某种程度上解决一些问题。

这个分库涉及：把大量段的分离，或者表分离，尽量保持一个数据库小一点。

3：建立索引：Access也有索引的，不过我设了和没设，没感觉到有区别（不像其它数据库，设置后效果太明显）。

4：压缩数据库，用久了压一压，数据库小点，感觉还是有点用处的。

 

晕，总结了一下，才发现access没多少可优化点，以前优化都是在尽量避免和access接触，基本上是程序上的优化。

 

仇：由于Access本身并不具备多少优化点，因此，程序上根本无法100%阻挡access的写入或读取，因此，总在某一时刻，数据库死锁了，最可怕的，最后还经常出现aspnet_isapi检测到死锁，重启应用程序池，这对本来内存就小的服务器是最致命的打击，从此，我恨access。

 

缺点：当access死锁时，这是相当可怕的，因为除了重启IIS，你几乎没有其它方式可以恢复网站的正常运行。

 

补充另外一招：调用GC.Collect()，这招可以释放Access未关闭链接而链接引用丢失时造成的临时锁。

 

最后，我必须总结一下：

 

1：access本来就是桌面数据库，还是不要勉强逼它吃多线程应用。

 

2：站点有点流量的，内存一定要够大，vsp买时，内存至少得1G以上够开个sql2000，多花点钱，省N多时间。

 

3：目前秋色园QBlog运行在sql2000下+sqlite辅助，一切正常。

 

4：本来是想写文本数据库（CYQ.Data数据框架操作文本）相关的文章，没想到写着写着写成这文章了，歪了。。。