• 企业400电话
  • 微网小程序
  • AI电话机器人
  • 电商代运营
  • 全 部 栏 目

    企业400电话 网络优化推广 AI电话机器人 呼叫中心 网站建设 商标✡知产 微网小程序 电商运营 彩铃•短信 增值拓展业务
    SQLite 性能优化实例分享

    最早接触 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、硬盘都不一样,所以性能测试最好还是以真机为准。该问题测试的时候在模拟器上很多问题都没有,因为硬盘比真机读写速度要高,所以避免了很多问题,测试的时候也就没有发现。
    数据库设计设计的时候得多考虑考虑,多想想以后怎么扩展,怎么升级,读写的时候性能怎么样

    您可能感兴趣的文章:
    • SQLite优化方法
    • android创建数据库(SQLite)保存图片示例
    • SQLite3中的日期时间函数使用小结
    • SQLite3中自增主键相关知识总结
    • C#操作SQLite方法实例详解
    上一篇:SQLite数据库常用语句及MAC上的SQLite可视化工具MeasSQLlite使用方法
    下一篇:SQL中使用ESCAPE定义转义符详解
  • 相关文章
  • 

    © 2016-2020 巨人网络通讯 版权所有

    《增值电信业务经营许可证》 苏ICP备15040257号-8

    SQLite 性能优化实例分享 SQLite,性能,优化,实例,分享,