最早接触 iOS 开发的时候了解到的第一个缓存数据库就是 SQLite，而后面也一直是以 SQLite 作为中坚力量使用，之前未曾接触过比较大量数据的读写，因此在性能优化方面关注的不是很多，此次对一个特定场景的较大数据批量读写做了一个性能的优化，使性能提高了10倍，有兴趣的来了解一下。
大概的应用场景是这样的：
每一次程序启动会从服务器拉取一些数据，对本地数据库两个表进行同步更新，不存在就会写入，存在就更新其字段。数据少则几十条，多则上千条。
由于缓存的数据可能会存在异步同时读写的问题，因此做了一个后台同步队列，所有缓存数据库操作都在这个队列里面，接着监控了一下写数据库的关键代码执行耗时，一千条数据更新到数据库就需要耗时 30 秒之久，磁盘写入在 1.5M/s 浮动， 虽然没有卡主线程，这个消耗就算是在后台也是无法容忍的。
核心数据库操作大概是这样的：
for 1000 : {
Select -> Update Or Insert
Select -> Update Or Insert
}
因此牵涉到了两张表，因此会有两次，经过测试，Select 一次几乎没有多少消息，可是 Update 或 Insert ( [FMDatabaseQueue executeUpdate:] ) 就消耗较大了，因为会写入磁盘，接着想到是不是能够将所有的 SQL 语句拼接起来，最后只想一次；再后来想到 SQLite 不是有事务 ( Transaction ) 嘛，于是尝试了一下利用 FMDB 的事务操作，在循环开始以前 [db beginTransaction] ，循环结束 [db commit]，包起来就行了。
增加事务以后的大概逻辑是这样的：
beginTransaction
for 1000 : {
Select -> Update Or Insert
Select -> Update Or Insert
}
commit
测试效果相当的好，整个耗时从 30 秒下降到2.8 秒左右了，并且仅增加了两行代码而已。
总结：
尽管利用事务取巧来提高性能，不过这样做其实并不安全，好在所属场景对这部分数据绝对一致要求不是太高。
模拟器和真机有时测试并不能重现同一个问题，因为所属架构、CPU、硬盘都不一样，因此性能测试最好还是以真机为准。该问题测试时在模拟器上不少问题都没有，因为硬盘比真机读写速度要高很多，所以避免了不少的问题，测试时也就没有发现。