Android 5棒棒糖SQLite性能

在Nexus5上进行测试，运行了棒棒糖更新，之后我的SQLite查询现在要花很长时间才能执行，我想这比在冰淇淋三明治中执行要长3、4倍

Android4附带了SQLite的3.7版本，Android5现在附带了改进的3.8版本，理论上至少可以提高50%的性能

然而，我一点也看不到这一点，SQLite在棒棒糖中的表现似乎很糟糕

与运行旧Galaxy 3的冰淇淋三明治并行测试我的查询需要1-2秒，而棒棒糖升级查询开始需要更长的10-15秒

DB已创建适当的索引

这个问题只存在于棒棒糖中

是否有人面临过类似的问题，以及如何解决的建议

示例查询和解释查询输出：

SELECT DISTINCT 
 t.route_id, s.stop_name, s.stop_id, s.stop_lat, s.stop_lon, s.location_type 
FROM 
 stops s 
 INNER JOIN stop_times st ON s.stop_id=st.stop_id 
 INNER JOIN trips t ON t.trip_id=st.trip_id 
WHERE 
 s.lon > -111.84006 AND s.lon < -111.81482 AND 
 s.lat > 34.839073 AND s.lat < 34.86432 AND 
 service_id IN (SELECT service_id FROM calendar WHERE saturday='1')

Sqlite 3.8引入了。它可能会做出不同的选择，但应该更好

在这里，我假设您的查询的查询计划在sqlite版本之间有很大的不同。你只发布了其中一个

请允许我引用《升级到NGQP的危害》中的一段摘录：

但是，与任何查询计划器更改一样，升级到NGQP确实会带来性能下降的小风险。这里的问题不是NGQP不正确、有缺陷或不如传统查询计划器。给出关于指数选择性的可靠信息，NGQP应始终选择与以前一样好或更好的计划。问题是一些应用程序可能在没有运行分析的情况下使用低质量和低选择性指数。较老的查询规划者对每个查询的可能实现的关注要少得多，因此他们可能因为愚蠢的运气而偶然发现了一个好的计划。另一方面，NGQP考虑了更多的查询计划可能性，它可以选择一个不同的查询计划，该计划在理论上工作得更好，假设索引良好，但由于数据的形状，在实践中会给出性能回归

总结：

新的计划者更依赖于正确的统计数据，以知道哪种策略将排除最多的行和最快的行 如果没有它们，它可能会做出错误的选择，选择使用错误的索引，甚至没有索引 您应该使用ANALYZE更新表统计信息，或者手动将典型/最坏情况下的统计信息插入统计信息表中

---

因此，看看运行ANALYZE是否有助于提高查询性能。在两个sqlite版本上比较前后的查询计划和性能，如果您将所有四种情况都发布给其他人以让他们看到差异，那就太酷了。

答案是重写查询并添加适当的索引。如果没有数据库模式和查询本身，没有人可以帮助您。我发现您的注释无效。按照Android版本重新编写SQL查询不是有效的解决方案。如上所述，查询在棒棒糖之外需要1-2秒。这个问题只局限于Android 5.0。所以你们不希望你们的查询在任何版本上花费几毫秒的时间？毫秒会很好：但让我恼火的是，它只在5.0上发生。我将用一个示例查询更新帖子。我已经通过优化查询解决了这个问题。R-Tree似乎是解决这个问题的正确解决方案，但我想避免在设备上运行时添加SQLite模块的复杂性。此外，我已经追踪到了游标逻辑的瓶颈，我的查询本身现在需要毫秒。我觉得您应该添加R-树指针作为解决方案，因为考虑到原始问题的上下文，它是有效的。在我使用全文搜索FTS3的情况下，ANALYZE将性能提高50倍。非常感谢。