>手头的问题
我们的 C# Windows 应用程序使用 EWS 托管 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 2007 限制为每个父文件夹 11 个动态搜索文件夹，因此根据约会的数量和访问约会的频率，它可能更不可行。使用现有的索引属性可能不可行，因为应用程序外部的用户可能会更改这些属性。如果您有某种方法可以确保您创建的约会只能从您的应用程序中访问或更改，那么那就是另一回事了。
数据库表是一个很好的方法，但有一个潜在的障碍，有些人直到为时已晚才看到。ItemId 是链接到扩展属性的明显选择，但 ItemId 不是常量。它是基于其他几个属性的计算属性。如果将项目移动到另一个文件夹，它可能会更改，并且也可能随着服务包的安装或足够的时间流逝而更改，或者我听说过。我至少可以确认第一个。ItemId 不适合长期存储，至少在没有额外检查的情况下是不可行的。可以存储 ItemId 和扩展属性。如果使用 ItemId 的绑定失败，请回退到扩展属性搜索。如果绑定成功，则根据数据库中的扩展属性检查它，以确保它匹配。如果项目不匹配，请在拥有项目后更新 ItemId。您是否需要使用约会对象以外的任何内容，即会议响应、转发通知等，或者这只与日历有关？
它并不漂亮，但它应该是一个合理的妥协。您可能仍然偶尔进行搜索，但只要用户不决定将约会移动到不同的文件夹或提前计划某些约会，它们应该很少而且相距甚远，即使这样，同步也应该有助于缓解这种情况。只需准备好在 Exchange 有升级时重新填充该表。
当然，如果Microsoft添加了索引其他属性的功能，或者甚至为此目的在 Exchange 搜索中的索引中添加了一两个空白字符串字段，我们就不会遇到此问题。哎呀，约会和相关对象的 GlobalObjectId 属性索引会有所帮助，但唉......不。我不喜欢重新利用现有的索引字段。并非所有约会都适用于约会以及用户需要或可编辑的约会。除非您确切地知道自己在做什么，否则重新利用这些领域可能会在未来产生不可预见的后果。
无论如何，我并不声称自己是 EWS/Exchange 所有事务的专家，所以也许有比这更好的方法。半信半疑。
媒体资源启用索引功能。我不熟悉在 Exchange 2007 中为哪些属性编制索引。由于应用程序似乎正在使用约会，因此也许您可以重新调整其他非约会属性之一的用途来存储唯一值。也许可以通过扩展属性使用 AssistantName 属性（以解决 EWS 架构和服务施加的限制）。这样，大多数客户端将不会将该属性用于日历项目。
根据本主题 http://technet.microsoft.com/en-us/library/jj983804（v=exchg.150）.aspx，该属性已编制索引（2013 年）。该属性已经存在了很长时间，因此可能会在 2007 年编制索引。
嘿，这是一个很长的机会，无论如何都不是最佳的，但也许它可能适用于您的场景。
在阅读了更多此线程之后，我发现您不是在寻找具有扩展属性的所有项目，而是在查找特定项目。 抱歉，我在第一反应中没有抓住这一点。 我同意仅搜索文件夹对您不起作用，因为每次搜索项目时都需要更新过滤器。 这显然会非常昂贵（可能比您目前的方法更糟糕）。 我的一个想法是创建一个按扩展属性排序的视图。 我可能是错的，但我相信您可以将此视图应用于上述搜索文件夹（请注意，我说的是显式创建搜索文件夹和视图并将它们存储在邮箱中，它们可以隐藏或暴露在搜索文件夹树下的 OL UI 中）。 搜索文件夹将仅筛选具有扩展属性的约会。 然后，视图将按属性值对文件夹进行排序。 在我对 ESE 内部的一些阅读中，我看到一些评论表明按属性排序将导致 Exchange 在 ESE 上创建索引（希望我现在能找到它）。 关于 ESE B 树指数的部分似乎证实了这一点：http://books.google.com/books?id=12VMxwe3OMwC&pg=PA73&lpg=PA73&dq=how+to+create+exchange+ese+indexes&source=bl&ots=D5hJyJIEo5&sig=ppZ6RFJh3PnrzeePRWHFJOwXgeU&hl=en&sa=X&ei=QQ7HUtgggvTbBdjcgfAP&ved=0CFwQ6AEwBQ#v=onepage&q=how%20to%20create%20exchange%20ese%20indexes&f=false
然后，您必须使用上面在搜索文件夹上使用的相同方法来查找符合您条件的特定项目。 当然，一个挑战是 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