在发送托管对象上下文save:消息之前，对托管对象所做的修改仅在内存中，不会提交给数据库。那么它如何对数据库执行查询呢？它必须执行标准的 SQL 查询，然后查询未保存的对象并合并结果，这应该很慢。
更新：例如，我有文章 <-> 标记多对多关系，并且我有许多未保存的文章。然后我想找到所有具有某些标签或在某些日期之间的文章。在数据库中，这将是对我们的关系表或日期字段的查询，并将使用适当的索引。但是对于未保存的对象，它必须遍历所有未保存的文章和/或其标签？或者对于未保存的对象，它也有一些类似数据库的存储？
默认情况下，Core Data 不会在您执行 fetch 时查询挂起的更改 - 您需要使用setIncludesPendingChangesfetch 请求的属性显式设置它。
假设您已启用此功能：我不确定您为什么认为查询未保存的更改会更慢。
如果您的 Core Data 实例由 SQLite 存储支持，那么您需要从持久存储（磁盘）中读取数据库。您未保存的对象仍将全部位于 RAM 中 - 访问这些未保存的对象比访问数据库中的对象要快得多。您可以并行执行这两个查询，然后合并结果 - 合并数组是微不足道的 - 这意味着几乎没有性能损失。
总是有例外和边缘情况，但一般来说不应该有明显的性能损失。
这是一个有趣的问题，我确实想知道当一堆对象在内存中时，大提取的效率如何。
我的猜测是内存中的对象被相当智能地管理，并且对象图的设置方式使得获取请求的开销最小化。虽然如果所有对象都已写入磁盘（仅因为“双重提取”），效率可能会稍低一些，但总体而言，拥有内存层而不必不断地写入和读取磁盘的好处会大大超过了这些类型的 fetch 请求性能的轻微下降。
我认为你要得到这个问题的答案的唯一方法就是自己做一些分析。如果你打开 Instruments，iOS 模拟器有一个 Core Data 工具可以帮助你分析获取请求。我会测试两次执行相同的 fetch 之间的区别：一次是在 fetch 之前处理所有待处理的更改，一次是在内存中处理一堆对象。如果你这样做，我很想看看这两个提取的结果！