我们目前有一个SQL联合数据库，它在大致相等的数据部分中分割了10个分片，并通过客户端ID进行过滤。
目前我们遇到执行过滤查询的性能问题，例如，为特定客户端运行查询可能需要3分钟才能在某些分片中返回4000行。但是，在同一个分片上的未过滤连接中运行完全相同的查询会在4秒内及时返回。一个值得注意的方面是，经历减速的分片往往包含更多的客户端，尽管数据较少。最可能的性能抑制器（我相信）将是索引以及与Filtered / Unfiltered连接相关的东西。
搜索周围我没有找到关于分片上的查询性能的更多信息/分片上的特定索引策略（除了Azure显然不支持索引视图）。我的印象（因此需要澄清）是索引应用于分片的所有成员，而不是逐个成员。
如果是前者，那么我们有点腌制，除了重新分析这个特殊的碎片，这是没有意义的，因为唯一的区别是客户端的数量，而不是数据的大小。我们要尝试的一些事情是明确地将过滤器添加到索引，甚至将过滤器添加到每个查询。可以说，我们不喜欢远离Filtered连接。
是否有其他人遇到过这个问题，或者是否可能提供一些指示：未经过滤的连接明显优于过滤后的连接？
提前致谢...
答案 0 :(得分：0)
联盟中的索引在联盟成员的基础上应用。如果您从单个索引成员开始并执行SPLIT操作，则索引将自动应用于SPLIT的产品。但是，如果在创建多个成员后应用了索引，则需要向每个成员显式添加索引。
所以希望你不是一个泡菜。
由于4月份宣布的新SKU不支持该功能，您可能希望考虑联合会的替代方案。