sqlite3_prepare_v2 不会返回花费太长时间（慢）和使用内存答案

【问题标题】：sqlite3_prepare_v2 doesn't return taking too long (slow) and using memorysqlite3_prepare_v2 不会返回花费太长时间（慢）和使用内存
【发布时间】：2012-10-03 06:11:07
【问题描述】：

我有一个 iOS 应用，有一个包含 1500 条记录的表。

我正在使用 FMDB，调用以下表单：

FMDatabase *db = ...
[db executeQuery:@"select num from a where b = ?", 6];

表“a”在“b”上有一个索引。

这在模拟器中运行良好，但在 iPad1 上需要很长时间。它会消耗内存，直到应用程序被杀死。 Instruments 说它卡在“sqlite3_prepare_v2”中。

原始查询还有一个“order by”子句。我已将其删除以进行测试。我什至可以完全删除 where 子句，它的行为仍然如此。

有什么想法可能是错的吗？

在此之前，其他查询正在运行。我之前曾从不同的线程访问过数据库，但没有任何其他线程正在进行访问。我原以为我可能有一个悬空交易，但事实也并非如此。

【问题讨论】：

“消耗内存”是否意味着内存使用量在稳步增加？它是卡在sqlite3_prepare_v2 还是从它调用的某个函数中？对此查询使用单独的数据库连接会改变什么吗？
是的，在 sqlite3_prepare_v2 调用中内存使用量增加。增加直到应用程序因内存不足而被杀死。创建第二个数据库连接似乎并没有改变行为，但它确实给了我缩小问题范围的想法，谢谢。

标签： ios ipad sqlite fmdb

【解决方案1】：

那么，您是否尝试将结果提取到FMResultSet？

而且，如果您使用的是 FMResultSet，您是否通过键入 [rs close] 来关闭结果集？

这些是需要考虑的重要事项。

【讨论】：

在获取结果集之前出现问题。发生在 sqlite3_prepare_v2 语句中。

【解决方案2】：

我想我找到了问题所在。我有两个线程，每个线程都有一个 FMDatabase 对象。我相信发生的事情是我在事务中使用第一个数据库对象插入了许多行。我有一个逻辑错误，我从未提交过交易。

虽然第一个数据库实例有这个大的待处理事务，但我正在尝试从第二个数据库实例的同一个表中选择所有。

显然这是造成这种情况的原因。显然在模拟器中，它并不明显慢。但它在 iPad1 上消耗了足够的内存和时间，导致应用程序被杀死。

【讨论】：