我有一个SQLite数据库，表中只有超过6,000行地址。这是一个只读数据库 - 在构建和部署应用程序后没有更新或更改。我有一个关于州字段的索引。我的应用程序使用一个简单的select语句来获取与给定状态匹配的所有行。我已经使用了解释和解释查询计划语句来查看我的查询正在使用索引。
大多数情况下，查询会在一秒钟内恢复 - 不是很好，但对我的应用程序来说已经足够了。
查询经常需要更长时间 - 甚至长达14秒，通常为3-4秒。在同一部手机上完全相同的只读数据库（和表）上完全相同的查询，由完全相同的二进制文件调用。
我可以看到没有发生垃圾收集，并且没有从监视logcat
生成异常有时会发生变化。一种创建不一致用户体验的变体。
似乎SQLite数据库系统正在被其他应用程序共享 - 例如电子邮件客户端。可能是我的查询在另一个应用程序的查询后排队，因此变化是由于共享SQLite数据库系统实际运行我的查询时？如果是这种情况，是否可以“创建我自己的SQLite实例”以便我可以获得一致的性能？
如果它不是一个共享的SQLite数据库系统（因此我确实拥有自己的实例），那么在其他一切相同的情况下，还有什么可能导致查询性能出现如此大的变化？
请注意，我不能轻易地将数据带入内存以在那里运行查询，因为行很长（有更多的信息而不仅仅是地址）而且我的代码中有许多其他部分可以使用更复杂的选择查询。我已经将性能变化缩小到这个问题的最简单的“select where state =”查询（请求帮助）。
答案 0 :(得分：3)
似乎SQLite数据库系统正在被其他应用程序共享 - 例如电子邮件客户端。
不完全是。 存储由其他应用共享。在Android 1.x和大多数2.x设备上，内部存储的格式为YAFFS2，一次只允许一个进程访问存储。对于运行ext4而不是YAFFS2的Android 3.0+设备（以及一些2.3设备），这应该不是问题。
可能是我的查询在另一个应用程序的查询后排队，因此变化是由于共享SQLite数据库系统实际运行我的查询的时间？
不完全是。但是，您的磁盘I / O可能排在另一个应用程序的磁盘I / O后面。