我们正在处理 Parse.com 数据库中的一个非常严重的错误，该错误对我们的应用程序有严重影响答案

【问题标题】：We are dealing with a very serious bug in Parse.com database that has severe implications to our application我们正在处理 Parse.com 数据库中的一个非常严重的错误，该错误对我们的应用程序有严重影响
【发布时间】：2015-07-31 11:15:49
【问题描述】：

我们正在使用 Parse.com 数据库处理一个非常严重的错误，该错误对我们的应用程序有严重影响。

一周以来，我们发现在过去 2 天的间歇性操作将我们的正常运行时间降低到不到 20%。

使用 Web 查询性能和分析工具，我们能够将问题提炼成一个明显的症状，该症状似乎锚定在 _User 表中 - 当系统关闭时会发生这种症状。我们无法找到根本原因或解决问题的方法：

说明：

当系统关闭时，对 _User 的所有查询尝试检索一组用户（“containedIn”）且该组有超过 1 个用户需要 30 多秒并超时。如果使用单个用户 ID（带有单个成员数组的“equalTo”或“containedIn”）发送相同的查询，则具有相同条件的相同查询会立即返回用户记录。

当我们尝试检索用户记录作为其他对象查询中包含的键时会发生同样的效果（即 includeKey:@“user”） - 如果我们在不包含用户的情况下运行该查询或检索单个记录，则查询会立即成功返回.包括具有多个响应的用户需要 30 多秒并超时。即使我们使用 query.limit=1 将查询限制为 1，但 containsIn 数组包含超过 1 个 ObjectID，查询也会超时。

请务必注意： 1）此时我们的 _User 计数为 180,000+，但其他集合有 MM 的记录并且没有显示任何此类行为，并且 2）如果“containedIn：”条件应用于不同的字段（例如用户名），则查询不会超时 3）我们目前整个星期都在 20GB 文件存储空间上下浮动。正如常见问题解答所述，我们没有看到跃升至 40GB，仅 98%-106% 的 20GB 存储利用率......也许这是一个潜在的根本原因，但我们只是不知道。

感觉好像有些东西在 _User 表的 objectId 索引上“死锁”了……或者该索引已损坏并且不断被“修复”锁定查询。

我们不知道为什么查询需要很长时间、为什么会失败或如何找到解决方案。我们需要 Parse 的某个人与我们一起解决这个问题，因为我们失去了一周的用户——他们觉得我们的应用程序似乎无法正常工作……

我们正在尝试从 PARSE 寻求一些人为支持，为期一周，但没有任何答复！！！

请帮忙

【问题讨论】：

现在我也很沮丧，因为我想帮忙。但我怎么能？在另一个帐户中，如何制作一个除了对大型用户表进行 containsIn 查询之外什么都不做的应用程序。那个应用程序能用吗？
我认为这个问题除了 Parse 之外任何人都无法解决。对于那些想要使用 Parse 的人来说，让这成为一个警告购买者。
似乎更难与他们取得联系，因为他们关闭了自己的帮助论坛。你试过谷歌组吗？
是的，我们确实在 Google 小组中提出了几次问题，但超过 5 天没有回复！！！我们每天 18 小时都在寻找问题并试图解决它，这很糟糕！任何人都知道如何联系解析另一种方式？我们还报告了一个错误并在上周四得到了回复，从那以后就没有任何回复了！！！

标签： android ios performance parse-platform parse-cloud-code

【解决方案1】：

Parse 给我们答复，他们检查并发现我们的数据库索引有问题，他们已经解决了这个问题。

服务器运行得很快，看起来我们已经结束了。

【讨论】：

我也有类似的问题。您是如何联系 parse 重置数据库索引的？
我也面临同样的错误“协议错误”。请帮帮我。