在Exchange上使用扩展属性慢速搜索项目
手头的问题
我们的C＃Windows应用程序使用EWS Managed API 2.0在用户的日历中创建约会。 每个约会都有一个具有独特价值的扩展财产。 它稍后使用FindItems和ItemView定位约会。
用户在第一次执行此搜索时会遇到严重延迟。 后续响应时间完全可以接受。
（“第一次”在这里有点模糊，因为用户可能会在当天晚些时候再次遇到延迟）
// locate ID of appointment where extended property value equals 1234: var filter = new Ews.SearchFilter.IsEqualTo(extendedPropertyDefinition, 1234); var view = new ItemView(1, 0); view.PropertySet = BasePropertySet.IdOnly; var folder = new FolderId(WellKnownFolderName.Calendar, new Mailbox("...")); var result = service.FindItems(folder, filter, view);
远程服务器是Exchange Server 2007 SP1 。
研究
MSDN将一些评论与搜索文件夹和受限制的视图联系在一起 ，但我不确定这些是否适用于我们的情况。
将视图应用于文件夹的操作会在商店中创建搜索文件夹 。 创建搜索文件夹时，会将其缓存以供以后使用。 如果用户尝试创建已存在的搜索文件夹，则使用缓存的搜索文件夹。 这使得未来的观看速度相当快。 默认情况下，Exchange不会无限期地缓存所有搜索文件夹。
特别是关于EWS ：
同样重要的是要注意这样一个事实，即第一次发布Exchange存储搜索查询时，它将非常缓慢地运行并且可能超时，而在将来的运行中它将毫无问题地响应。 这是由执行存储搜索时Exchange服务器上发生的后端进程引起的。
他们建议为非变化的非动态查询创建搜索文件夹，这在我们的案例中似乎不合适，因为每个约会的查询都不同。
如果应用程序需要具有一组固定不变参数的特定查询，则可以使用搜索文件夹。 […]搜索文件夹仅对不变的非动态查询有用。
我们需要的是在本质上创建一个“索引” – 在数据库中 – 在属性上，确保所有对这个特定属性的搜索都是快速的，无论时间或频率。
是否有可能“索引”这个属性？ 是否可以在客户端或服务器端配置任何内容以消除此初始延迟？
我遇到了与集成项目相同的问题。 我希望有一个很好的解决方案……
您无法为尚未由Exchange编制索引的属性创建索引。 如果约会数量增长足够高，则为每个文件创建搜索文件夹是不可行的。 单个文件夹上的搜索文件夹太多会导致进一步的问题，因为当将新项目添加到文件夹时，它们都需要更新。 这是我的理解，至少。 此外，Exchange 2007每个父文件夹限制为11个动态搜索文件夹，因此根据约会的数量和访问频率，它可能更不可行。 使用现有的索引属性可能不可行，因为这些属性可能会被应用程序外部的用户更改。 如果您有某种方法可以确保您创建的约会只能从您的应用程序访问或更改，那么这是一个不同的故事。
数据库表是一个很好的方法，但有一些人可能会看到一个潜在的障碍，直到为时已晚。 ItemId是链接到扩展属性的明显选择，但ItemId不是常量。 这是一个基于其他几个的计算属性。 如果项目被移动到另一个文件夹，它可以改变，它也可能随着安装服务包或给予足够的时间通过而改变，或者我听说过。 我至少可以证实第一个。 ItemId不适用于长期存储，至少没有额外的检查。 您可以存储ItemId和扩展属性。 如果使用ItemId的绑定失败，则回退到扩展属性搜索。 如果绑定成功，则根据数据库中的扩展属性进行检查，以确定它是否匹配。 如果项目不匹配，请更新ItemId。 您是否需要处理Appointment对象之外的任何事情，即会议响应，转发通知等，或者这仅与日历有关？
它不漂亮，但应该是一个合理的妥协。 您可能仍然偶尔进行搜索，但只要用户没有决定将约会移动到不同的文件夹或提前计划某些约会方式，它们就应该很少，即使这样，同步也应该有助于缓解这种情况。 。 如果有升级到Exchange，请准备好重新填充该表。
当然，如果Microsoft已经添加了索引其他属性的function，或者甚至在Exchange搜索中为索引添加了一个或两个空字符串字段，我们就不会遇到此问题。 哎呀，关于约会和关联对象的GlobalObjectId属性的索引会有所帮助，但是唉…没有。 我不喜欢重新利用现有的索引字段。 并非所有这些都适用于约会，而且这些约会往往是用户要求或可编辑的。 除非你确切知道自己在做什么，否则重新利用这些领域可能会产生不可预见的后果。
无论如何，我并不声称自己是EWS / Exchange所有事务的专家，所以也许有更好的方法。 拿一粒盐。
没有办法为您的房产开启索引。 我不熟悉在Exchange 2007中索引哪些属性。由于您的应用程序似乎正在使用约会，因此您可以重新调整其他一个非约会属性以存储您的唯一值。 也许通过扩展属性使用AssistantName属性（以解决EWS架构和服务强加的限制）。 这样，大多数客户端都不会将该属性用于日历项目。
根据这个主题http://technet.microsoft.com/en-us/library/jj983804(v=exchg.150).aspx ，该属性被索引（2013年）。 该物业已存在很长时间，因此可能会被编入2007年的索引。
嘿，这是一个很长的镜头，并不是最佳的，但也许它可能适用于你的场景。
在阅读了这个post之后，我发现你并不是在寻找具有扩展属性但是具体项目的所有项目。 对不起我在第一次回复时没有抓到。 我同意单独的搜索文件夹对您不起作用，因为每次搜索项目时都需要更新filter。 这显然是相当昂贵的（可能比你目前的方法更糟）。 我的一个想法是创建一个由您的扩展属性进行排序的视图。 我可能错了，但我相信您可以将此视图应用于上面的搜索文件夹（请注意，我正在谈论明确创建搜索文件夹并查看并将其存储在邮箱中，它们可以隐藏或暴露给OL UI在搜索文件夹树下）。 搜索文件夹将仅过滤具有扩展属性的约会。 然后，View将按属性值对文件夹进行排序。 在一些阅读中，我一直在做ESE内部，我看到一些评论表明按属性排序会导致Exchange在ESE上创建索引（希望我现在可以找到它）。 关于ESE B-Tree索引的部分似乎证实了这一点： http ： //books.google.com/books？id = 12VMxwe3OMwC＆p = PA73＆ltg = PA73＆div = how + to+ create+exchange+ese+indexes&source=bl&ots=D5hJyJIEo5&sig=ppZ6RFJh3PnrzeePRWHFJOwXgeU&hl = EN＆SA = X＆EI = QQ7HUtgggvTbBdjcgfAP＆VED = 0CFwQ6AEwBQ＃v = onepage＆q = 20to％20create％20exchange％20ese％20indexes＆F如何％=假
然后，您必须使用上面在“搜索文件夹”中使用的相同方法来查找符合条件的特定项目。 当然，一个挑战是Exchange抛弃你的索引的问题（这可能是你当前的方法中发生的事情）。 也许您可以通过编程方式定期触摸搜索文件夹，以确保不会发生这种情况？ 此链接还有助于了解创建搜索文件夹/视图对性能的影响： http ： //technet.microsoft.com/en-us/library/cc535025%28EXCHG.80%29.aspx
如果你找到一个好的解决方案（或者这个有效），我很有兴趣听到它（我相信很多其他的也是如此）。 哦，交流发展的喜悦:-)
使用扩展属性作为条件创建搜索文件夹是可行的方法。 您将在搜索文件夹最初构建时支付价格，但只要文件夹存在并且正在运行，它就会在创建索引后由Exchange自动更新。 我们非常成功地使用这种技术来找到众所周知的“大海捞针”。
http://msdn.microsoft.com/EN-US/library/dd633687(v=exchg.80).aspx