SQL Server怎么也启动不了了（忘了我原来对它做了啥了），懒得折腾或者装别的数据库了，引用下网上查到别人的。

http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison

需要说明的是SQLite老版本第一个1000插入的测试似乎比这个快得多，见这里： http://www.sqlite.org/speed.html

http://www.mongodb.org/pages/viewpage.action?pageId=1475411

http://sqlserverperformance.wordpress.com/2010/02/07/some-initial-insert-test-benchmarks-on-sql-server-2008-r2/

我的结果，老机PD820，7200RPM SATA硬盘，插入是1620条的情况下：每条都sync到磁盘上的话，1.6秒；如果不sync，是0.2秒，大概每秒8000多。当前还不包括查询和其它操作，没有做完；不过做完了也没法和SQL类的比了。

这是python版的结果，生成数据就得用0.015秒，算上其它逻辑的开销，将来C版nosync应该能再提高50%到200%，sync是没戏了（瓶颈在IO）。说白了就是达到和别人相似的性能应该没什么脑力障碍，也无需参考别人的算法。

不过现在已经比别人快或者和别人差不多快是不作数的。SQL Server这样要干一大堆额外工作的就不要说了，SQLite、Mongo之流也都有更多动作降低速度。等我这个实现完整了也避免不了，毕竟这东西在底层基本是同质化的。

关于SQL Server，上面那个测试里提到如何提速写日志的时间，这个想根本解决只有靠硬件。因为日志的保障数据不出问题的原理就是，每次必须写到硬盘上，接下来才做真正的更新操作。SQLite也有事务，但它这块简单得多。

其实现在数据库的测试对一般人完全没有参考价值。就我的实践来看，对于数据库的局部设计和实现，绝不可能有什么突破性的东西，最多是些许的提高。恰恰是慢的数据库更应该引起兴趣：它提供了什么特性，让它不得不付出代价？

如果nosync的话，很显然还得至少保证下数据不会因为掉电、死机、崩溃之类的意外事故损坏数据。另外可以提供批量操作的接口让使用者选择是不是马上写回硬盘。这就有点事务的意味了，不过谨记不要真的实现完整数据库功能。

注意：批量操作并非说就是根据用户申请临时nosync就够，很显然的，比如bulkinsert一类的功能，明显应该把数据记录在内存里拼接在一起，一次性写入一大坨。想必SQLite在一个Transcation里每秒3、4万的插入就是这么来的。

另外，印象里BerkeleyDB在某些测试中有特别可怕的插入性能，10倍左右于SQLite的操作数，这个有空得确认和研究一下（估计是上面方法加吃内存吃出来的）。不过这个初步考虑不是应该优先去做的事情，因为使用场景并不多。

顺便夸奖python两句，虽然慢的吓人，但风格比较适合原型包括算法类的，慢能放大瓶颈反而对找问题有帮助 -_-。