从上个月起，秋色园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优化有关的都有什么来着：
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 数据框架操作文本）相关的文章，没想到写着写着写成这文章了，歪了。。。
