iOS核心数据索引属性没有提高性能

Posted 2023-03-04

【中文标题】iOS核心数据索引属性没有提高性能

【英文标题】：iOS Core Data Indexed Attribute not improving performance

【发布时间】：2012-04-01 19:36:45

【问题描述】：

我有一个在 iPad 上运行的 Core Data 数据库。它有 30,000 个联系人，其中包含名字、姓氏等属性。

使用 NSCompoundPredicate 的搜索性能不是很好。我正在使用两个 LIKE 谓词（关于名字和姓氏），搜索 30,000 个联系人大约需要 1500 毫秒。然后我尝试将“索引”属性添加到名字和姓氏字段（使用 XCode Data Modeller UI），但性能似乎完全相同。

自从将 Indexed 属性添加到这两个字段后，我已从数据库中删除所有对象并重新填充它。为了开始使用索引，我是否需要做更多的事情？我是否应该期望通过索引复合谓词中使用的两个字段来提高性能？

我在真实设备（iPad3）上运行。用 1500 毫秒搜索 30,000 条联系人记录似乎不太好 - 是否符合课程标准？

非常感谢。

【问题讨论】：

您是否将它们加载到 tableView 上？

稍后我会这样做，但我正在为搜索计时，而这是花费时间的搜索（我只是在搜索期间构建一个匹配对象的 NSArray）

您是否从 Core-Data 获取 30000 个联系人？如果是的话，你一次取多少？

否，但数据库中有 30000 个联系人。通常搜索只会返回少数几个。

您的查询是否以通配符开头？

【参考方案1】：

LIKE 搜索成本很高，无论您要搜索的属性是否已编入索引。

许多应用程序（包括 Apple 自己的应用程序）通过以用户不会注意到的方式限制搜索来避免此问题。例如，在像联系人这样的应用程序中输入时进行搜索并不真正希望将查询与人名的所有可能子字符串进行匹配。相反，它匹配名字或姓氏以查询开头的人。

为了进一步优化，还请考虑如果没有 LIKE 和 BEGINSWITH 获得的完整的 Unicode 精通、大小写和变音符号识别匹配，您可能会侥幸逃脱。 Apple 的 DerivedProperty 示例展示了如何通过存储搜索属性的“规范化”（即所有相同的大小写，没有变音符号，其他无关的东西消失）版本并使用依赖于字典顺序的谓词（例如 @987654327）来获得更好的性能@)。

关于这些和相关技巧的更多细节可以在过去 WWDC 的一些核心数据会议中找到，尤其是2010 Session 137, "Optimizing Core Data Performance on iPhone OS"。

【讨论】：

除此之外，我认为在这种情况下索引不应提高性能这一事实的信息会有所帮助。

这里有更多信息，说明如果 like 运算符以通配符开头而不是只包含一个通配符，为什么会特别慢：myitforum.com/cs2/blogs/jnelson/archive/2007/11/16/108354.aspx