伏龙阁资源网

SQLite 性能优化实例分享
站长资源 2024/12/27 佚名
2 0

最早接触 iOS 开发了解到的第一个缓存数据库就是 SQLite，后面一直也以 SQLite 作为中坚力量使用，以前没有接触到比较大量数据的读写，所以在性能优化方面关注不多，这次对一个特定场景的较多数据批量读写做了一个性能优化，使性能提高了十倍。

大致应用场景是这样：

每次程序启动会从服务器拉取一些数据，对本地数据库两个表进行同步更新，不存在就写入，存在就更新其字段。数据少的时候几十条，多的上千条。

由于缓存的数据可能会存在异步同时读写，所以做了一个后台同步队列，所有的缓存数据库操作都在这个队列里面，然后我监控了一下写数据库的关键代码执行耗时，一千条数据更新到数据库就能耗时 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、硬盘都不一样，所以性能测试最好还是以真机为准。该问题测试的时候在模拟器上很多问题都没有，因为硬盘比真机读写速度要高，所以避免了很多问题，测试的时候也就没有发现。
数据库设计设计的时候得多考虑考虑，多想想以后怎么扩展，怎么升级，读写的时候性能怎么样

广告合作：本站广告合作请联系QQ：858582 申请时备注：广告合作（否则不回）
免责声明：本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除！
www.wwsws.com 伏龙阁资源网
39,976影音资源
44,792技术资源
21,817软件资源
651,128站长资源

更新日志

友情链接

杰晶网络 DDR爱好者之家 桃源资源网 杰网资源 富贵资源网 南强小屋 铁雪资源网 幽灵资源网 万梅资源网 狼山资源网 白云岛资源网 昆仑资源网 相思资源网 明霞山资源网 内蒙古资源网 黑松山资源网 茶园资源网 饿虎岗资源网 大旗谷资源网 常春岛资源网 岱庙资源网 兴国资源网 快活林资源网 蝙蝠岛资源网 帝王谷资源网 白云城资源网 伏龙阁资源网 清风细雨楼 天枫庄资源网 圆月山庄资源网 无争山庄资源网 神水资源网 移花宫资源网 神剑山庄资源网 无为清净楼资源网 金钱帮资源网 丐帮资源网 华山资源网 极乐门资源网 小李飞刀资源网 凤求凰客栈 风云阁资源网 金狮镖局 鸳鸯亭资源网 千金楼资源网 更多链接