分享一个SQLite性能优化实例

　　最早接触iOS开发了解到的第一个缓存数据库就是SQLite，后面一直也以SQLite作为中坚力量使用，以前没有接触到比较大量数据的读写，所以在性能优化方面关注不多，这次对一个特定场景的较多数据批量读写做了一个性能优化，使性能提高了十倍。
　　大致应用场景是这样：
　　每次程序启动会从服务器拉取一些数据，对本地数据库两个表进行同步更新，不存在就写入，存在就更新其字段。数据少的时候几十条，多的上千条。
　　由于缓存的数据可能会存在异步同时读写，所以做了一个后台同步队列，所有的缓存数据库操作都在这个队列里面，然后我监控了一下写数据库的关键代码执行耗时，一千条数据更新到数据库就能耗时30秒之久，磁盘写入在1。5Ms浮动，虽然没有卡主线程，这个消耗即使在后台也是不可容忍的。
　　核心的数据库操作大概是这样的for1000：｛SelectUpdateOrInsertSelectUpdateOrInsert｝
　　由于牵涉到两张表，所以会有两次，经过测试，Select一次几乎没有多少消息，可是Update或者Insert（〔FMDatabaseQueueexecuteUpdate：〕）就消耗大了，因为会写入磁盘，然后想到是不是可以把所有的SQL语句拼接起来，最后只想一次；再后来想到SQLite不是有事务（Transaction）嘛，于是尝试了一下利用FMDB的事务操作，在循环开始前〔dbbeginTransaction〕，循环结束〔dbcommit〕，包起来就行了。
　　增加事务之后的大概逻辑：beginTransactionfor1000：｛SelectUpdateOrInsertSelectUpdateOrInsert｝commit
　　测试效果非常好，整个耗时从30秒下降到了2。8秒左右，仅仅增加了两行代码。
　　总结：
　　踩过的坑，走过的坎，都是以后的经验
　　虽然利用事务取巧来提高了性能，但是这样做其实并不安全，好在所属场景对这部分数据绝对一致要求不是太高。
　　模拟器和真机有时候测试并不能重现同一个问题，因为所属架构、CPU、硬盘都不一样，所以性能测试最好还是以真机为准。该问题测试的时候在模拟器上很多问题都没有，因为硬盘比真机读写速度要高，所以避免了很多问题，测试的时候也就没有发现。
　　数据库设计设计的时候得多考虑考虑，多想想以后怎么扩展，怎么升级，读写的时候性能怎么样。
　　分享一个SQLite性能优化实例《Linux就该这么学》（linuxprobe。com）