我们目前有一个SQL Federated DB，它由10个碎片组成，数据的部分大致相等，由客户端ID过滤。
目前，我们在执行过滤查询时遇到了性能问题，例如，为特定客户端运行查询可能需要3分钟以上才能在某些碎片中返回4000行。然而，在同一碎片上的未过滤连接中运行完全相同的查询会在4秒内及时返回。一个值得注意的方面是，经历速度减慢的碎片往往包含更多的客户端，尽管数据较少。最可能的性能抑制因素（我相信）是索引和与已筛选/未筛选连接相关的东西。
经过搜索，我没有发现太多关于碎片查询性能/碎片上特定索引策略的信息（除了Azure显然不支持索引视图）。我的印象（因此需要澄清）是，索引应用于shard的所有成员，而不是逐个成员。
如果是前者，那么我们就有点麻烦了，除了重新分发这个特定的碎片之外，考虑到唯一的区别是客户端的数量，而不是数据的大小，这是没有意义的。我们将要尝试的几件事是将筛选器显式添加到索引中，甚至将筛选器添加到每个查询中。可以肯定地说，我们不喜欢离开过滤连接。
其他人有没有遇到过这个问题，或者可能提供一些指导，说明未过滤的连接明显优于过滤的连接？
提前感谢。。。
联合会中的索引是在逐个联合会成员的基础上应用的。如果从单个索引成员开始并执行SPLIT操作，则索引将自动应用于SPLIT的乘积。但是，如果在创建多个成员后应用了索引，则需要显式地向每个成员添加索引。
所以希望你没有陷入困境。
你可能想考虑联合会的替代方案，因为4月份宣布的新SKU不支持该功能。