Android 变量 SQLite 选择查询性能 - 任何解释？

Question

我有一个 SQLite 数据库，表中有 6,000 多行地址。这是一个只读数据库 - 在应用程序构建和部署后没有更新或更改。我在 state 字段上有一个索引。我的应用程序使用一个简单的选择语句来获取与给定状态匹配的所有行。我已经使用解释和解释查询计划语句来查看我的查询正在使用索引。

大多数情况下，查询会在一秒钟内返回 - 不是很好，但对我的应用程序来说已经足够好了。

查询通常需要更长的时间 - 甚至长达 14 秒，通常为 3-4 秒。在同一部手机上对完全相同的只读数据库(和表)进行完全相同的查询，由完全相同的二进制文件调用。

我可以看到没有垃圾回收发生，监控 logcat 也没有产生异常

只是有时会发生变化。造成不一致用户体验的变体。

似乎 SQLite 数据库系统正在被其他应用程序共享 - 例如电子邮件客户端。会不会是我的查询在另一个应用程序的查询后面排队，因此变化是由于共享 SQLite 数据库系统实际开始运行我的查询时造成的？如果是这种情况，是否可以“创建我自己的 SQLite 实例”以便获得一致的性能？

如果它不是一个共享的 SQLite 数据库系统(因此我确实有自己的实例)，在其他一切都相同的情况下，还有什么可能导致查询性能出现如此大的变化？

请注意，我不能轻易地将数据放入内存中以在那里运行查询，因为行很长(包含比地址更多的信息)并且我的代码的许多其他部分都使用更复杂的选择查询。我已将性能变化缩小到最简单的“select where state =”查询这个问题(请求帮助)。

Answer 1

It appears that the SQLite database system is being shared by other apps - such as the email client.

不完全是。 存储 由其他应用共享。在 Android 1.x 和大多数 2.x 设备上，内部存储的格式为 YAFFS2，一次只允许一个进程访问该存储。这在运行 ext4 而不是 YAFFS2 的 Android 3.0+ 设备(和一些 2.3 设备)上应该不是什么问题。

Could it be that my query is being queued behind another app's queries and thus the variation is due to when the shared SQLite database system actually gets to run my query?

不完全是。不过，您的磁盘 I/O 可能排在另一个应用程序的磁盘 I/O 之后。