iOS 平台 SQLite 性能优化

开始

在 ios 平台,数据永久化的存储方式就那么几种,比如说 coredata,比如说realm,还有nosql的几种方案,但是很遗憾,nosql的几种方案支持的功能都还是太少,这样就让对它们的选择显得十分鸡肋——毕竟,如果是简单的应用的话,那就还不如其他方案来的方便快捷——虽然nosql是趋势。

这次我们来谈谈另一种比较常见的储存方案——sqlite,这个东西很厉害,它是一个用c实现的无需服务器的sql框架,它就一个文件配合框架就可以实现一个简单的数据库了,拥有大部分数据库的查询功能,性能也还不错。

需求

一般使用的话,sqlite的默认配置也是足够了的,但有一些情况下,我们还是需要更快的体验——比如作为输入法的词库的时候。很多人觉得,用sqlite很快,但作为输入法的词库就显然太慢了,难道sqlite就不能更快一步吗?当然可以,sqlite的默认配之为了适应大部分人的使用环境所以设置的十分保守,我们可以让它更快。

Pragma

Pragma 是 sqlite 特有的一个配置语句,与之配合的有一些对应的参数,我们在连接数据库后可以对其进行修改,但下次连接的时候,还是需要再次配置的。

你可以在这里看到完整的所有 Pragma 参数,不过对性能有重大影响的参数也就那么几个,不是很多的。

执行 pragma 就像你在 sqlite 里执行 sql 语句一样,没有返回值。

page_size

大小必须是2的倍数,一般来说,现在应该都是默认4096了,但如果不是,那你就手动设置一下,总而言之,你最好把它设置为与你系统硬盘的分页大小。

synchronous

关闭同步,数据库只有在设备突然断电之类情况下可能导致数据库损坏——嗯,这种情况,我觉得可以接受。

locking_mode

当不需要同时有多个进程同时访问数据库时(我们就在自己的app里访问数据库而已)那就不需要默认的normal,设定锁定模式为exclusive模式,可以保证同一时间只有一个进程访问数据库,这样可以避免不必要的冲突控制,增加数据库速度。

journal_mode

日志能够保证数据提交的完整性,一旦提交出现问题,数据库就可以实现回滚。不过,现在大部分情况下ios的稳定性已经足够,如果你甚至都不会给数据库写入内容,那么干脆把日志模式关闭好了。这样可以大大加快sqlite的速度。

cache_size

这个缓存,默认是0,也有不少人推荐1,我建议你自己多测试几次,我自己的感受是有和没有区别有点,但大小好像没啥区别了……

mmap_size

配置内存映射,但实际上好像并没有开启,这取决于你的sqlite版本。

query_only

如果你和我一样只是用来查询,那么就开启这个选项。

单件模式

说完了参数配置,我们再来说说其他方面,比如整体的使用姿势。如果说你在整个应用中都不会有其他进程访问数据库(一般也不应该有),那么就做一个单件模式,然后保持长链接就好了,并没有必要一直持续地连接和断开,同时还可以避免你意外地同时去争夺数据库资源造成数据的丢失和文件损坏。

比如说,这样:

索引

恰当地为你需要经常查询的字段进行索引,并且避免使用太复杂的sql语句以确保查询会使用索引。一个有效的测试方式是使用 sqlite 内置的 explain 功能查看语句的执行流程,如果其中包含 idx ,那基本差不多。

使用 explain 来查看sql语句的预计执行过程

避免不恰当的 sql 语句

一般来说,你应该只获取你要获取的内容,不要去做  SELECT * FROM  这一类脑残的语句,同时,在获取内容的时候,比如你可能写的是这样的:

如果是大量查询,那么你最好这样来写:

使用字段索引来获取内容,可以避免查找,大大加快取值速度。

创建表

创建表也有优化的地方可以说说,比如如果你的字段能非空,就非空,如果能唯一那自然就最好了!

 

总结

以上就是我在开发落格输入法的过程中对sqlite的一些性能优化探索,可能并不适用于所有的开发情况。而且高级的编译优化也还没有去接触,希望能够帮助到你。

延伸阅读

Performance Optimization of SQLite on iOS with Xamarin

本文由 落格博客 原创撰写:落格博客 » iOS 平台 SQLite 性能优化

转载请保留出处和原文链接:https://www.logcg.com/archives/2316.html

About the Author

R0uter

如非声明,本人所著文章均为原创手打,转载请注明本页面链接和我的名字。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注