sql-server - Multi-Tenancy 聚集索引设计

Question

我有一个 Multi-Tenancy 应用程序，我想要数据的聚集索引以支持快速范围查询。

如果我像这样设计我的聚集索引:

(SystemID, EntityID, IsHidden)

SystemID是 Multi-Tenancy 实例的唯一标识符， 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 )而不是物理集群键加入。