当前位置：首页 > news >正文

数据库多租户设计：创业早期也别把 tenant_id 当摆设

news 2026/7/4 6:56:40

数据库多租户设计：创业早期也别把 tenant_id 当摆设

企业 SaaS 从第一天就会遇到多租户问题。早期为了快，团队可能只在用户表里加一个 tenant_id，查询时凭记忆手写条件。短期看没问题，长期风险很大：漏加条件导致数据串租户，权限判断散落各处，后续做企业审计和数据导出会非常痛苦。创业早期可以简单，但不能把 tenant_id 当摆设。

多租户设计的底线，是任何数据访问都必须明确属于哪个租户。租户隔离是 SaaS 产品的生命线，一旦出问题就是品牌危机。

真实案例：某 SaaS 创业公司上线 8 个月后，客户投诉看到其他公司的数据。排查发现是搜索接口漏了 tenant_id 条件。团队连夜排查所有查询，发现 12 处类似问题。此后建立统一查询层，所有数据库访问强制带 tenant_id。数据隔离问题是企业客户最敏感的合规红线。

一、租户边界要进入数据模型

flowchart TD A[Tenant] --> B[User] A --> C[Project] A --> D[Document] A --> E[Usage Event]

核心业务表都应该有租户归属，尤其是项目、文档、知识库、用量事件、审计日志、任务记录。不要只在用户表里存 tenant_id，然后通过用户间接推导所有数据。间接推导越多，越容易出现绕过路径。

有些全局表可以不带 tenant_id，例如系统配置、公开模板、模型供应商配置。但只要数据和客户业务有关，就应该明确租户边界。这个原则越早建立，后续越少补洞。建议在数据模型评审时把 tenant_id 作为必检项。

对比分析：user 表存 tenant_id vs 各业务表存 tenant_id。user 表方案：查询需要 join users，容易漏条件，性能差，串租户风险高。各表存 tenant_id：查询简单，不容易漏，审计方便，合规成本低。企业 SaaS 几乎都选择各表存 tenant_id 方案。代价是存储稍大，但安全和合规价值远超成本。

二、查询层要统一注入条件

async function findDocuments(ctx, filter) { return db.document.findMany({ where: { tenantId: ctx.tenantId, ...filter } }); }

不要依赖每个开发者记得加 tenant_id。可以通过 Repository、ORM middleware、数据库 Row Level Security 或统一查询上下文注入租户条件。手写条件越多，漏掉的概率越高。

统一查询层还方便做审计。每次跨租户访问、管理员访问、后台任务访问，都可以在同一个入口记录原因和操作者。企业客户问"谁看过我的数据"时，系统要能回答。跨租户访问要单独记录审计日志，并支持导出审计记录。跨租户访问要单独记录审计日志。

三、后台任务也要带租户

{ "job_type": "generate_report", "tenant_id": "t_1001", "resource_id": "doc_7788" }

多租户漏洞常出现在后台任务。前端请求时有用户上下文，任务入队后如果只保存 resource_id，worker 执行时可能绕过租户校验。任务 payload 必须带 tenant_id，并在执行前重新验证资源归属。

模型调用、文件导出、邮件发送、账单统计都属于高风险任务。它们往往跨多个系统，一旦租户上下文丢失，排查会很困难。把 tenant_id 当成任务的一等字段，是早期就该养成的习惯。所有后台任务都要有租户上下文传递测试，CI 中强制检查。所有后台任务都要有租户上下文传递测试。

四、测试要覆盖串租户风险

it("does not return documents from another tenant", async () => { const docs = await findDocuments(ctxOfTenantA, {}); expect(docs.every(d => d.tenantId === "tenant_a")).toBe(true); });

多租户隔离不能只靠代码评审。核心查询、搜索、导出、批处理、管理后台都要有串租户测试。尤其是新增筛选条件和关联查询时，最容易因为 join 或 where 顺序出错。

测试数据要至少包含两个租户，并故意使用相似资源名。这样才能发现查询条件遗漏。只用单租户测试环境，永远测不出串租户问题。建议 CI 中强制运行多租户隔离测试，作为上线必经检查。