多租户群集索引设计

Question

我有一个多租户应用程序，我希望数据的聚集索引支持快速范围查询。

如果我设计我的聚集索引是这样的：

(SystemID, EntityID, IsHidden) 

SystemID是为多租户实例的唯一标识符，EntityID是实体和IsHidden的身份是一个标志，该行是否在结果中出现了或不。 SQL Server能否有效地抛出不属于系统的所有数据以及隐藏数据？并确定这些列指定的顺序是否重要？

如果我有一个查询，像这样：

SELECT * FROM MyTable WHERE SystemID = @pSystemID AND IsHidden = 0 

我想我试图做的是有效的分区表，以便属于特定系统以及隐藏数据的所有行物理分组紧靠在一起。这样，根据对该数据的查询，它可以轻松地被丢弃。

这是好还是坏？ （我倾向于好，我不期待有很多插入物正在发生）

Answer 1

让它变成这样：(SystemID, IsHidden, EntityID)。在之后IsHidden列将使EntityID基本上无用，因为EntityID已经是唯一的。例如（WHERE SystemID=@SystemID AND IsHidden=0）搜索标准将仍然需要搜索该租户的整个范围，因为IsHidden=0的行遍布整个范围。在EntityID之前移动此列可实现更高效的范围扫描。

您将遇到的一个问题是，搜索特定的EntityID默认情况下效率低下（WHERE EntityID=@EntityID）。您可以通过在EntityID上添加一个非聚集索引来改进，但这只能解决部分问题。这些问题大部分将来自出现与其他表的连接，就像一个细节表将加盟条件：

FROM Master JOIN Detail ON Master.EntityID = Detail.ParentEntityID 

由于这些查询变得更加复杂和候选行的范围增大，非效率EntityID/ParentEntityID键上的聚簇索引开始减少，直到它们达到the tipping point并且基本上被忽略。如果可能的话，请确保所有这些连接指定聚集索引键代替：

FROM Master JOIN Detail 
    ON Master.SystemID = Detail.SystemID 
    AND Master.IsHidden = Detail.IsHidden 
    AND Master.EntityID = Detail.ParentEntityID 

的问题将是最建模工具（如EF或LINQ）往往会通过逻辑主键的加入（该EntityID ）而不是物理集群密钥。