sqlite使用总结

随便说说，也是一点编程的备忘。Sqlite是一个不错的嵌入式数据库，这个嵌入式基本上是精巧和轻量的代名词，sqlite引用的场景很多，firefox和android的内部都是有应用的，这个小数据库代码不多，但是功能比较完备，这里不说如何使用。如果想知道如何使用，请自己参考数据库教材，和这个URL http://www.codeproject.com/KB/database/CppSQLite.aspx，当然了，如果有更好的CPP封装，也不反对。这个小数据库不光光支持C，也支持很多其他语言，基本上编程top 10 的语言都支持。

我这篇文档，想先简单总结一些技术细节。还有其他方面，比如数据类型，数据库格式。外键、insert冲突处理、视图性能，内存数据库的使用方式。我会慢慢补充的。

      并发和锁

         程序员一般都是很关心效率的，对于数据库查询的时候，都是很关心并发和锁的问题。到底是行级锁还是表级别锁。Sqlite在这个地方是表级别的读写锁，换句话说，写的时候不能查。查的时候不能写。我这里单单说明一下windows的实现，sqlite内部使用的是关键区和信号模拟，如果在windows下，关键区的效率是很高的。

         我们知道，sqlite是一个单文件数据库，在实际应用的时候，会出现多个进程同时访问一个数据库文件的情况。不幸的是，这个情况下，sqlite采取的是锁住整个文件的方式，当然实际上采取的是部分锁的情况，比如这个表占用了数据库文件的一段，那么sqlite仅仅锁住这一段。但是即便是这个样子，依然在高并发的场景下，不能满足我们的需求。这个时候就要考虑是否采取其他的替代方案，甚至这个时候，采取我们自己写的数据文件也是可行的。

         当然以上的场景有一个十分重要的前提，就是你要搞清楚你用sqlite的场景，是否一定要用到sqlite的数据库功能，如果仅仅是查询数据，不删除修改数据，完全没有必要引入sqlite。

         对于多进程同时读写数据库文件的场景，sqlite的操作，例如执行sql语句不一定每次都会成功，有可能会返回 SQLITE_BUSY，代表当前数据库正忙。返回这个数值，其实就应该像返回 IO_PENDING的处理方式一样，我们要写一个简单的循环。直到返回SQLITE_OK为止。

         在最新的sqlite实现中，给我们提供了  sqlite3_busy_handler 函数，数据库返回不忙的时候，会调用这个函数设定的callback。这就不需要我们来写循环了，对于性能是一个比较好的优化。详细见 http://sqlite.org/c3ref/busy_handler.html

         关于多线程，这里多说一句，就是从3.5以后sqlite可以做到多线程共享一个数据库连接cache，这个可以有效的控制内存的数量。见 http://www.sqlite.org/sharedcache.html

        

数据一致性和插入性能

         数据库一个重要属性，就是保证数据的一致性。Sqlite在这个上面做了很多的工作，可以保证在断电的情况下，要不修改数据成功，要不没有成功。这个我们在一般的编程的时候，基本上可以忽略这个因素。具体细节可见 http://sqlite.org/atomiccommit.html

         但是，在有的场景下，数据库的一致性和插入性能往往是一对矛盾。在保证一致性的时候，sqlite在每次修改数据库的时候，会首先生成一个数据修改日志文件，然后再将这个文件合并到主数据库文件，这个场景下，对于磁盘IO的性能是很有影响的。我们知道cpu要比磁盘IO快不止一个数量级，在实际应用的时候，你会发现插入往往是sqlite数据库操作的一个瓶颈。

         其实这个性能瓶颈也很好解决，根据操作系统的属性，磁盘文件（包括硬盘和SSD）如果想提高写的性能，那么最好是成块成批的写。不涉及操作系统底层，我们仅仅从最简单的sql语句上说，如果在有任何修改的是，都提交一个事务，然后再完成修改后提交事务。这个时候sqlite是会采取批量成块写的策略。我在实际应用中，如果不启动事务，单条修改就提交，和批量修改、最后提交，要慢一个数量级。

所以说，我们在实际应用中&#