我應該在多租戶系統中按租戶 ID 通常對錶進行分區嗎？

我們正在建構一個系統，其中 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“過早的悲觀化”？

如果您使用的是 InnoDB，則聚集索引將（通常）已經按AccountId. 如果寫入次數通常較低/相當平衡，則不需要按 each分區 AccountId。

分區可能有助於以下場景：

1. 您需要快速刪除整個帳戶的數據或僅恢復單個帳戶的數據。
2. 您有很多帳戶，但寫入很少，而其他帳戶則有大量寫入。如果您將高容量帳戶分區到它們自己的分區，則更容易執行碎片整理/索引重建等操作，而不會影響其他帳戶。
3. 您需要保持非活動帳戶的數據可訪問，但希望使“活動”數據盡可能小/易於管理。

如果您最終進行了分區，那麼每個人都這樣做AccountId可能會有點過分——最好確定一些關於如何/何時進行分區的標準。

編輯：正如 RickJames 有用地指出的那樣，MySQL 不能/不會對分區表強制執行 FK 約束。因此，您需要創建一種替代方法來強制執行這些方法，這是額外的程式碼成本和無效數據的風險。因此，如果您最終對事物進行了分區，那麼升級到沒有該限制的數據庫可能是有意義的（SQL Server 將是“支持聚集索引，可以在不中斷的情況下實現分區”類別的下一步。

引用自：https://dba.stackexchange.com/questions/275301