Android SQLite性能分析

╰+哭是因爲堅強的太久メ 2022-08-27 02:30 307阅读 0赞

作为Android预置的数据库模块，对SQLite的深入理解是非常有必要的，可以从中找到一些优化的方向。这里对SQLite的性能和内存进行了一些测试分析，对比了不同操作的执行性能和内存占用的情况，粗略地列在这里算是作个小结。

## 1. 基本架构 ##

先了解一下SQLite主要架构 (详见《The Definitive Guide to SQLite》)， 需要关注的是Compiler和Backend两个模块。正因为有一个虚拟机的存在，所以才有了Compiled Statement的价值，因为它可以减少前置的编译时间，直接到VDBE上执行。而Backend端的Pager，则是重要数据管理者，真正决定者数据操作的性能，以及内存占用。

![SouthEast][]

这里不再赘述，详细的内容还是阅读有关SQLite介绍的资料。

## 2. 性能 ##

这次测试基于Sumsung i9103和Google Nexus S1进行。使用Python脚本及adb指令通过Intent操作Android应用进行数据库操作。

### i. SELECT操作 ###

首先观察到SELECT在不同记录数下的峰值分布，可见整体上有上升的趋势。正如SQLite官方说的它并不适合存储大量数据，一定要控制其中的记录数量。

另外SELECT操作性能也取决于查询的栏位个数，而***[@行云][Link 1]***进一步确认和返回栏位的内容大小有关，也就是栏位的内容和多少也需要权衡。

![SouthEast 1][]

### ii. 关于事务 ###

事务是提高SQLite操作性能的一个重要技术，特别是SQLite实现了WAL，使得事务与SELECT不会互斥，大大提高了应用的性能。参见附2。

下面是未使用事务时，三类操作的平均值：

![SouthEast 2][]

使用了事务后，各个操作的性能大幅下降。

![SouthEast 3][]

但是问题是事务提交的时间会变长，这个时间一是需要形成新的峰值，另外也要平分到各个操作来看：

![SouthEast 4][]

所以不能贪多，事务还是要及时提交。另外注意， 虽然Compiled Statement有利于性能表现，但还不如使用事务的效果来得直接。

### iii. 不同机型的操作性能 ###

先看SELECT操作的平均值在两种机型上的表现, 可以看到i9103上的波动性比较大，而Nexsus S1则一直保持稳定:

![SouthEast 5][]

散点图,可以观察到时间分布情况:

![SouthEast 6][]

再看另外三个操作的表现(上下两部分false和true分别表示为未使用事务和使用事务的情况):

![SouthEast 7][]

运用WAL可以大幅提升性能，不过它也有一个副作用。它会导致数据查询需要进行两次，可以理解为一次在db文件，一次在wal文件。具体原因参见<<***The Definitive Guide to SQLite***>>最后一章。WAL是满1000Pages时才会合并到主数据库里，这个时机称为checking point, 可以进行配置。按默认的Page Size:1024计算，也就是当WAL文件接近1M时，进行检查。如果没有活动的事务使用这些pages,就会提交。而WAL的大小，对SELECT的影响表现不同。

下面是WAL对查询性能峰值影响的测试数据(i9103上测试)，图中的true,false表示是否有WAL文件存在。

![SouthEast 8][]

\*整体的平均值相差在1ms，但峰值的才是真正值得注意的。

为了避免WAL过大，可以选择调用SQLiteDatabase::disableWriteAheadLogging()强制合并到主数据库文件，这个调用会异步在SQLite内部执行，不会明显阻塞用户的线程。

\*另外，SQLiteDatabase::query()只是对SQLiteDatabase::rawQuery()的封装，多了一个字串组装的过程，反而不如直接使用SQLiteDatabase::rawQuery()。

## 3. 内存  ##

SQLite以Page为单位存储数据，默认一个Page有1024字节，然后通过B- Tree组织起来(Table使用B+ Tree组织):

![SouthEast 9][]

Lookaside则是SQLite应用的内存管理的技术，优化了内存的使用效率，主要思想是先分配一整块内存, 分成若干个slots，然后SQLite再按需使用。这和许多小内存分配器的思想是一样的。详见附1。

再解释一下Page Cache Overflow, 主要是在一个Page中的记录的数据无法刚好放在一个Page内，还要使用额外的另一个Page空间， 这就是Overflow Page。

![SouthEast 10][]

Android还有个万能dumpsys, 使用dumpsys meminfo可以查看到一个进程的SQLite使用的内存信息。如:

**SQL**

**                heap:      265          MEMORY\_USED:      265**

**  PAGECACHE\_OVERFLOW:       73          MALLOC\_SIZE:       46**

** **

** DATABASES**

**      pgsz     dbsz   Lookaside(b)          cache  Dbname**

**         4       60             17      199/114/1  webviewCache.db**

**                                          1/541/1  (pooled \# 1) webviewCache.db**

. cache的三个值分别是:

Page Cache的命中次数、未命中次数，以及Page Cache个数。可以在Android源码中的**SQLiteDebug.java**以及**[ActivityThread.java][]**找到细节的内容。

. page size, db size的单位是KBytes， Lookaside(b)是指使用多少个Lookaside的slots。

. 对于Heap和Overflow Pages，SQLiteDatabase的内存回收可能没有那么及时，可以调用SQLiteDatabase::releaseMemory()进行主动释放。

\*使用SQLite的PRAGMA可以直接获取一些通过SQLiteDatabase获取不到信息，当然如果SQLite不支持，也会抛异常出来，详见附4。

转载请注明出处: [http://blog.csdn.net/horkychen][http_blog.csdn.net_horkychen]  SQLite是一个非常精致的系统，很值得研究学习。

## 参考 ##

1. [SQLite Dynamic Memory Allocation][]

2. [Write-Ahead Logging][] 或 [SQLite的WAL机制][SQLite_WAL]

3. The Definitive Guide to SQLite( SQLite权威指南, 两处关于架构和Overflow page的截图来于此书.)

4. [PRAGMA Statement][]

5. [官方文档][Link 2]

6. [NEC关于Android系统上存储器操作性能的研究报告][NEC_Android] (里面有讲述SQLite因为其随机性访问的机制而在不同文件系统上的性能差异)

7. [Android开发中的SQLite优化][Android_SQLite]

[SouthEast]: /images/20220824/a0f18aaa62cf4e8cb9d5bacad9759069.png
[Link 1]: http://blog.csdn.net/wy5761
[SouthEast 1]: /images/20220824/4e30f4412a44462781e0f99f8766f7d5.png
[SouthEast 2]: /images/20220824/6fdf738ae9124991ae4ca0c4572ed31c.png
[SouthEast 3]: /images/20220824/e9c47ed55b804fcf8683a15b2370a7a9.png
[SouthEast 4]: /images/20220824/2ef73b11e9ee495c94a0af1872fe579a.png
[SouthEast 5]: /images/20220824/ce921cc01e504ab28251865850bc2d72.png
[SouthEast 6]: /images/20220824/6516ee15eff04c4ca4175922dda30b60.png
[SouthEast 7]: /images/20220824/df072739a5b04bdbb94196b94b7ad058.png
[SouthEast 8]: /images/20220824/5efd6a7f214f4fc9b6648a1b696fd06b.png
[SouthEast 9]: /images/20220824/85dd9ec2ef124eeebce70a81e19b4757.png
[SouthEast 10]: /images/20220824/44e4c0fbcd65496192a8f84deb4dcc37.png
[ActivityThread.java]: http://code.metager.de/source/xref/android/4.2/frameworks/base/core/java/android/app/ActivityThread.java
[http_blog.csdn.net_horkychen]: http://blog.csdn.net/horkychen
[SQLite Dynamic Memory Allocation]: http://sqlite.org/malloc.html
[Write-Ahead Logging]: http://www.sqlite.org/draft/wal.html
[SQLite_WAL]: http://www.cnblogs.com/frydsh/archive/2013/04/13/3018666.html
[PRAGMA Statement]: http://www.sqlite.org/pragma.html#pragma_schema_version
[Link 2]: http://www.sqlite.org/docs.html
[NEC_Android]: https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CC4QFjAA&url=%68%74%74%70%3a%2f%2f%73%74%61%74%69%63%2e%75%73%65%6e%69%78%2e%6f%72%67%2f%65%76%65%6e%74%73%2f%66%61%73%74%2f%74%65%63%68%2f%66%75%6c%6c%5f%70%61%70%65%72%73%2f%4b%69%6d%2e%70%64%66&ei=GcJfU4avG8WRkAXZg4GIBQ&usg=AFQjCNGRi1dFkEWvZlWhG8ODjRZOJotddA
[Android_SQLite]: http://blog.csdn.net/horkychen/article/details/18892223