Android 变量 SQLite 选择查询性能 - 有什么解释吗？

Question

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

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

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

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

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

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

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

请注意，我不能轻易地将数据放入内存以在那里运行查询，因为行很长（除了地址之外还有更多信息），而且我的代码还有许多其他部分使用更复杂的选择查询。我已将性能变化范围缩小到仅针对此问题的最简单的“select where state =”查询（请求帮助）。

Answer 1

SQLite 数据库系统似乎正在被其他应用程序（例如电子邮件客户端）共享。

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

可能是我的查询在另一个应用程序的查询之后排队，因此变化是由于共享 SQLite 数据库系统实际开始运行我的查询？

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