sqlite3性能的简单测试

      北京网站建设一般采用access数据库就足够了。
　　我想对于80％的网站来说，它们的数据量采用access数据库已经足够了。使用mysql或者sqlserver这些中型数据库，往往需要增加额外的使用费，而且数据量不大的时候，它们所反映的性能跟access数据库并没有多大的区别，故对于一般"玩家"来说并不容易接受。最近sqlite数据库异军突起，采用其作为后台数据库的"玩家"也越来越多，我接触它也有一年多的时间了，但都是在嵌入式平台上面使用，因为数据量小，一直没有对其进行过特别的性能测试。近期我也想"玩"一个网站，sqlite和access之间的选择就摆在我面前了，事实胜于雄辩，就做了一个小程序来测试。
　　测试环境是奔4 3G + 512内存 + vs2005 c#。由于网上有人说加上下面的三句话：
　　　PRAGMA synchronous = OFF;
　　　PRAGMA page_size = 4096;
　　　PRAGMA cache_size = 70000;
可以让sqlite的性能大幅度增加（不知道是否体现在超大数据量的时候），我也特地尝试了一下。
采用事务提交的方法，每次插入5w条数据。不执行上面三句话时执行时间大都是2 s，少数是3s。执行了上面三句话后大多数是3s ，少数是2 s。执行查询( id >10000 and id < 20000 ) 之间的数据，两者执行时间都是0.005s ，查询count(*) 获取所有数据条数时，加了三句话0.72~0.73s 比不加所耗的时间0.73s 快了一点点。25w条数据的文件大小为123兆。
　　access数据库用的是2003格式，这里不由得要郁闷一下，access其实本身并不支持事务提交，它是通过OleDbTransaction来实现的，它在事务提交中给我的感觉跟一条一条插入毫无区别，唯一的区别就是出错了会回滚事务。所以它插入完25w条数据所消耗的时间是远远无法跟sqlite比较的。反正应用中几乎也用不到大数据量事务提交，只好忍了。但是需要导入数据的话.....嘿嘿
　　相同的查询语句，access用了0.047～0.06s，与sqlite相比，差距明显。查询count(*) 获取所有数据条数时，用了0.06～0.07s，比sqlite稍有优势。25w条数据的文件大小为177兆。
　　综合来说，我觉得还是sqlite优势比较明显。但是access数据库维护要方便很多。