在多租户数据库中索引 TenantID答案

【问题标题】：Indexing TenantID in Multi Tenant DB在多租户数据库中索引 TenantID
【发布时间】：2011-12-30 00:06:06
【问题描述】：

我正在为一个应用程序创建一个多租户数据库。我在每个表方法中都使用了 TenantID，并且效果很好。我正处于性能调优阶段。

我的问题是是否应该为每个表中的每个 TenantID 编制索引以优化搜索，因为数据库上的每个查询都会在此列上进行过滤？

期待任何建议。

谢谢

【问题讨论】：

【解决方案1】：

对于每个利用设计的多租户特性的查询，您都需要一个包含tenantId 的索引。问题是，tenantId 应该出现在索引结构的哪个位置？当然答案是视情况而定。尝试建立索引，使具有最大选择性的字段排在第一位。

例如，假设一个表在各州 (50) 和 10 个租户之间分布均匀，我会将索引构建为 State，然后是 TenantId；对于具有 1000 个租户的同一张表，我将构建索引 TenantId，然后是 State。

在实践中，这两个索引都可能派上用场（让优化器对其进行排序）。

【讨论】：

【解决方案2】：

虽然在建立索引时需要考虑很多因素，但根据我的经验，（唯一）聚集索引与tenantId + PK 一样工作得很好，所有 PK 查询都可以在复合键上查找。

这具有将tenantID 放在非聚集索引中的额外优势，因为SQL Server 使用聚集键作为从非聚集索引返回到表的引用。

但请注意页面拆分，因为插入几乎总是在页面中间，这种方法肯定会针对读取进行优化。考虑填充因子为 70 并注意碎片，确保定期维护索引（无论如何你都想要这个）

祝你好运。

【讨论】：

唯一聚簇索引是指将每个表设置为具有由表当前主键和TenantID组成的复合主键吗？还是您的意思是在表上设置自定义聚簇索引？
你可以选择任何一种方式。我假设您有一个身份等作为表上的主键。在这种情况下，从技术上讲，租户 ID 不是主键的一部分，如果您已经设置了 FK，则可能难以制作复合键。我上次走这条路时所做的是在租户 ID 和标识列上创建一个唯一的聚集索引，并在标识列上创建一个非聚集主键。您目前的表架构是什么？
我同意，tenantId 应该是所有聚集索引键中最左边的列，所有谓词和连接都应该包括 tenantId。
目前它只有一个主键，而tenantID 只是另一个不可为空的列。例如 EmployeeTable = EmployeeID PK, TenantID... 目前没有设置 FK 键。我认为可以在 PK 列上指定唯一聚集索引，因此它必须是复合键，即 EmployeeID 和 TenantID 都是 PK 的？？？
它会像这样分解，Employytable.employeeID 将是一个非聚集主键。然后，您将有一个关于tenantid 和employeeid 的复合聚集索引。例如：create table EmployeeTable ( employeeid int identity(1,1) primary key nonclustered, tenantid int, firstname varchar(200) --... and so on ) create unique clustered index IXCU__EmployeeTable__tenantId__EmployeeID on EmployeeTable (tenantid, employeeid)