关于sqlite多线程

这几工作需要，用到sqlite多线程功能，这几天研究了一下，验证了一下结果，供大家参考：

1、如果是SQLITE_OPEN_FULLMUTEX，也就是串行化方式，则对于连接时互斥的，只有一个连接关闭，另外一个连接才能读写

2、如果是SQLITE_OPEN_NOMUTEX，则是多线程模式，对于写是互斥的，但是如果一个连接持续写，另外一个连接是无法写入的，只能是错误或者超时返回。不过一个连接写，多个连接读，是没问题的。windows版本模式是SQLITE_OPEN_NOMUTEX

3、如果要多线程写并发，只有一个办法，就是连接->写->关闭连接，而且需要开启超时sqlite3_busy_timeout，不过这样效率很低，因为一条一条写入的话，利用不上事务

4、sqlite通过事务插入效率还可以，大约就是1000条/秒

 

5、sqlite的数据类型操作非常灵活，可以写入任意自定义类型

6、如果要断电等意外也完全保证数据完整性，PRAGMA synchronous=FULL，对于大数据量提交，性能和synchronous=OFF相差很小。

7、对于大数据量写入，例如一次提交100MB以上的事务，设置cache_size很有必要，默认是例如：PRAGMA cache_size=400000，有时候提交速度会成倍提升。

8、sqlite事务的insert或者update等是很快的，但是commit是很慢的，例如提交200MB的事务，在win7+酷睿T9300+4GB内存+7200转磁盘+10GB的数据库上，commit会花费5分钟左右，在usb3.0的上U盘上，花费大约15分钟，在USB2.0的U盘上，1个半小时后还没有完成（没有等到结果，因为是NTFS格式，造成U盘写入太频繁，产生了坏道，尝试了两个U盘都是如此，格式化为exFAT就没问题）

9、对于commit意外退出，大数据量的时候，例如200MB，下次再次进入的时候，哪怕只是一个select,为了保证数据完整性，sqlite都要经过很长时间（和commit完成时间差不多）的rollback才能返回select结果，如果自作主张删除临时的journal文件，则会造成数据库崩溃。