Dynamics crm 搜索简单实体关系的速度非常慢

我们在我们的机构使用CRM 4.0，目前没有升级计划，因为我们在过去一年半的时间里对CRM进行了定制和扩展，以配合我们的流程

模型的一小部分是简单的层次结构，我们有一组学习室，这些学习室与描述该学习室可用课程的另一个实体有一对多的关系。 另一个实体有一份对任何课程表示兴趣的所有潜在和注册学生的名单

这一点非常简单，工作非常好，并被建模为3个自定义实体

现在，我们有一个管理应用程序，它读取房间，然后想显示该房间的课程，但只显示有注册学生的地方

在SQL中，这被简化为：

SELECT DISTINCT r.CourseName, r.OtherInformation
FROM Rooms r
  INNER JOIN Students S
    ON S.CourseId = r.CourseId
WHERE r.RoomId = @RoomId

这确实非常接近CRM生成的最终SQL。 我们使用Crm查询实体、筛选器和链接实体来表示相同的结构

现在的问题是，CRM将定制实体的数据规范化为一个基表，该基表包含所有共享的标准CRM实体数据，然后是一个扩展基表，该扩展基表包含我们的定制。为了提供对此的平坦访问，它创建了一个合并两个表的视图。 此视图是生成的SQL使用的视图

现在，基表有索引，但视图没有

我们所面临的问题是，我们所要做的就是返回满足内部联接的课程，这足以证明存在条目，并且CRM使其选择不同，因此我们只返回一个项目作为空间。 起初，这工作得非常好，但现在我们有数千个查询，它需要30秒以上，当然，除了短信之外，任何东西都会导致超时

我相信我们可以在CRM中创建和更改表的索引，这并不被认为是不受支持的修改；但是，关于观点呢？ 我知道，如果我们改变一个实体，那么它的视图就会被重新创建，这当然会让我们在发生这种情况时重做索引

有没有办法向CRM4.0提示我们需要一个特定的索引

另一个消息来源建议，如果您遇到这样的问题，那么最好将数据放在一起，但这并不是我在尝试设计我们的解决方案时感到舒服的事情

我曾考虑过在其中加入一个新的实体，其中只有RoomId、CourseId和注册人数，但这也有点令人难以置信的骇客味道；毕竟，索引将解决复制此数据的需要，并具有某种触发器，在每次学生操作后更新数据

最后，虽然我知道我们目前仍停留在CRM4上，但这是我们可以期望在CRM2011中解决的问题吗？这肯定会增加升级这一已有5年历史的产品论据的分量。

我看不到任何结论性的答案。微软提到的问题是引用完整性（这里不是问题）和升级复杂性。您提到了不受支持的添加视图并通过升级和实体更改对其进行管理的选项。这是一个选项，尽管它不受支持，也很有黑客味，但它应该会起作用

FetchXml确实具有聚合，但查询执行计划仍使用视图：以下是从事件中的简单选择计数生成的SQL：

'select 
top 5000 COUNT(*) as "rowcount"
, MAX("__AggLimitExceededFlag__") as "__AggregateLimitExceeded__" from (select top 50001 case when ROW_NUMBER() over(order by (SELECT 1)) > 50000 then 1 else 0 end as "__AggLimitExceededFlag__" from Incident as "incident0"  ...

我看不到一个支持你的问题的解决方案

---

如果您正在构建一个外部管理应用程序，并且在本地托管CRM 4，那么您可以绕过CRM API直接转到数据库进行查询。不支持，但允许您解决此问题。

由于视图是“动态的”（从概念上讲，每次使用它们时，它们的内容都是从基表动态生成的），因此通常无法对它们进行索引。然而，SQLServer确实支持一种称为“索引视图”的东西。您需要在视图上创建一个唯一的聚集索引，并且查询分析器应该能够使用它来加速您的加入。

我将添加这一点作为一个潜在的答案，尽管我不认为这是一个可持续的或确实有效的长期解决方案

---

在分析了CRM自动定义的索引之后，我意识到在查询中选择更多信息就足以满足索引的列要求，现在查询运行不到一秒钟。

FetchXML会提供不同的解决方案吗？我意识到解决这个问题的一个更有效的方法是，SQL将分组并选择计数大于0的位置；但看起来分组和聚合直到2011年CRM2011才被添加？只是觉得清楚这一点很重要；如果延长超时时间，则RetrieveMultiple会工作，并且确实返回正确的结果；这就是为什么我特别关注数据库而不是发布我的C#；谢谢你证实我所担心的，至少！有趣的是，我找到了一个类似于你建议的解决方案，但也许不是太好。事实证明，如果我向select语句添加另一个不相关的列，查询优化器会突然意识到它可以使用索引，整个过程在一秒钟内运行。当然，选择更多的数据以简单地将其丢弃是违反直觉的，但至少查询满足了定义索引的列并工作。虽然这修复了这个bug，但它并不优雅，最终我觉得它是不可持续的，所以我现在保留这个问题。您是否创建并更新了原始视图列的统计数据？尝试一下，然后删除不相关的列，看看优化器是否工作得更好；明天我会与DBA联系。这不是准确的答案，但我会接受，因为它非常接近正确的轨道，我怀疑在不了解我们的CRM安装的情况下，是否可以更准确地回答它