主页 / dba / 问题 / 275301
Accepted
Andrey Agibalov
Asked: 2020-09-11 05:45:40 +0800 CST

我应该在多租户系统中按租户 ID 通常对表进行分区吗？

  • 772

我们正在构建一个系统，其中 10 个表中的数据与 Accounts 相关联。一个典型的表如下所示：

create table Things(
    accountId varchar(64) not null,
    internalId varchar(64) not null,
    externalId varchar(256) as (concat(accountId, '-', internalId)) stored,
    ...
    primary key (accountId, sourcedId),
    unique (externalId),
    foreign key (accountId) references Accounts (id)
);

所有查询要么有accountIdinwhere子句，要么使用externalId. 没有跨账户查询。

我们预计总共有 200 个帐户。其他表（如Things）的大小从某些表的每个帐户 5 行（总共 1000 行）到某些其他表的每个帐户 225K 行（总共 45M 行）不等。（这些是我们用于性能测试的数字 - 它们是最大数字）

数据库大小约为 150 GB。95% 的场景是读取。

RDBMS 是 Mysql 8.0.16 (AWS RDS)。

我们目前没有任何性能问题，也没有试图让任何事情更快地运行。但我想知道不分区表是否Things是accountId“过早的悲观化”？

mysql performance

2 个回答

  1. 分区通常更多的是关于管理（在更新仓库时交换分区等）而不是一般 OLTP 场景中的性能，特别是如果您的所有数据都在同一个驱动器/阵列上，可能会导致性能下降。

    如果您稍后需要分区，您可以选择通过不同的属性进行分区，也许分区以便更新、更活跃的数据可以保存在最快的驱动器上。如果是这种情况，那么您已经为自己做了更多的工作，因为您需要在实施新的分区方案之前取消选择现有的分区方案。

    因此，虽然这至少是一个小观点，而不是 100% 的事实，但我想说现在分区还为时过早。

    • 1
  2. Best Answer

    如果您使用的是 InnoDB，则聚集索引将（通常）已经按AccountId. 如果写入次数通常较低/相当平衡，则不需要按 each分区 AccountId。

    分区可能有助于以下场景：

    1. 您需要快速删除整个帐户的数据或仅恢复单个帐户的数据。
    2. 您有很多帐户，但写入很少，而其他帐户则有大量写入。如果您将高容量帐户分区到它们自己的分区，则更容易执行碎片整理/索引重建等操作，而不会影响其他帐户。
    3. 您需要保持非活动帐户的数据可访问，但希望使“活动”数据尽可能小/易于管理。

    如果您最终进行了分区，那么每个人都这样做AccountId可能会有点过分——最好确定一些关于如何/何时进行分区的标准。

    编辑：正如 RickJames 有用地指出的那样，MySQL 不能/不会对分区表强制执行 FK 约束。因此，您需要创建一种替代方法来强制执行这些方法，这是额外的代码开销和无效数据的风险。因此，如果您最终对事物进行了分区，那么升级到没有该限制的数据库可能是有意义的（SQL Server 将是“支持聚集索引，可以在不中断的情况下实现分区”类别的下一步。

    • 1

相关问题