两层隔离对比总览：隔离粒度、成本、扩展性、管理开销权衡
在租户隔离架构中，“Database per Tenant” 与 “Schema per Tenant” 代表了资源边界与安全策略的两个极端。选择哪个方案，本质上是在 隔离粒度、运营成本、扩展性 与 管理开销 四项约束中寻求平衡。本章提供一张总览图谱，帮助架构师在项目初期做出最关键的选型决策。
架构决策前提： 本章对比仅针对“单租户独立数据库”与“共享数据库独立Schema”两种经典模式。第三种“共享表模式”（通过 tenant_id 字段隔离）不在本次对比范围内，因其隔离性已偏离架构方案的安全基线。
核心维度对比矩阵
以下表格从五个关键维度对两层隔离方案进行定量与定性分析：
| 对比维度 | Database per Tenant | Schema per Tenant |
|---|---|---|
| 隔离粒度 | 进程 / 实例级（强隔离） | 逻辑命名空间（弱隔离） |
| 运营成本 (TCO) | 高（独立进程，内存与连接独占） | 低（共享进程，资源复用率高） |
| 水平扩展能力 | 强（独立实例可随意迁移、拆分） | 弱（共享实例易触及 CPU/IO 天花板） |
| 管理开销 | 复杂（监控点分散，备份策略多） | 简单（单实例运维，统一 DDL 部署） |
| 租户级恢复 (RTO) | 快（直接恢复独立备份集） | 慢（需从实例级备份中修复单个 Schema） |
| 连接管理难度 | 高（连接数随租户线性增长） | 低（连接复用率高，易于池化） |
关键权衡点分析
权衡一：安全性与资源效率的对立
Database 模式 利用数据库内核的进程级隔离，天然防御 SQL 注入跨越租户。但效率低，每个独立实例必须预留独立的 Buffer Pool 与连接数，内存冗余度非常高。
Schema 模式 依赖应用层强制显式过滤（如 WHERE tenant_id = ?），资源利用率极高。但若出现过滤遗漏或 SQL 注入，将直接导致跨租户数据越权访问。从架构信任链路来看，Schema 模式要求应用层承担更多安全责任。
扩展性与成本的天平
一个拥有 5000 个租户的平台，若采用 Database 模式进行部署：
- 资源消耗：假设每个独立实例最小申请 256MB 内存，仅内存开销就接近 1.25TB。加上每个实例至少 10MB 的共享内存浪费，整体开销呈指数级上涨。
- 管理复杂度：DBA 需要维护 5000 个备份集，监控 5000 个性能仪表盘，这对运维团队是巨大的灾难。
采用 Schema 模式，5000 个 Schema 可以稳定运行在 1-2 个 64GB 高性能实例中。但当单实例无法支撑时，Schema 模式的分片方案（例如基于分库分表中间件的二次路由）将带来远超 Database 模式的架构实施成本与数据迁移风险。
管理开销：“最后一公里”的交付差异
| 运维场景 | Database 模式 | Schema 模式 |
|---|---|---|
| 备份策略 | 需编写自动化脚本遍历所有 DB 执行备份 | 单实例备份，天然包含所有租户数据 |
| 版本升级 | 所有实例必须滚动升级，风险窗口长 | 升级一次数据库实例，所有 Schema 即刻受益 |
| 资源告警 | 必须构建统一的聚合监控层查看全局状态 | 只需关注单一实例的 Wait Events 与 Slow Log |
| DDL 变更 | 需要执行 N 次 DDL 语句，过程耗时且易出错 | 执行一次 DDL，所有 Schema 的表结构同步变更 |
⚠️ 常见风险点与避坑指南
- Schema 模式的“吵闹邻居”：一个租户的慢 SQL 占满共享实例的 IOPS 或 CPU，会导致所有租户服务受损。必须在数据库层部署 SQL 限流（如 PolarDB 的 Statement Queue）或使用资源组（Resource Group）进行隔离。
- Database 模式的“连接风暴”：当应用服务启动时，同时建立数千个数据库连接会瞬间打爆操作系统的端口与 PID 限制。必须在业务层部署连接池代理（Proxy）进行连接收敛与缓冲。
- Schema 模式的恢复陷阱：误操作删除某个 Schema 后，从备份恢复通常需要重建整个实例，导致全局停机。必须依赖“逻辑备份 + 数据订正”工具，或采用 Flashback 闪回技术。
选型决策模型：四个判定节点
在架构方案中，我们无法接受模糊的“看情况”。以下是具体的决策树门槛：
- 合规性审计门槛：业务是否属于金融、医疗等强合规行业？
- 是 → 选择 Database 模式（确保独立审计日志与网络隔离）。
- 否 → 进入下一节点评估。
- 数据量容量门槛：单租户数据量是否超过 500GB？
- 是 → 选择 Database 模式（方便独立备份、恢复与垂直扩展）。
- 否 → 进入下一节点评估。
- 租户密度门槛：规划租户总数是否超过 2000？
- 是 → 选择 Schema 模式（实例成本与运维密度优先）。
- 否 → 进入下一节点评估。
- 团队能力门槛：团队是否有能力处理“吵闹邻居”与跨租户 SQL 注入风险？
- 是 → 选择 Schema 模式（最大化资源利用率）。
- 否 → 选择 Database 模式（用硬件成本换取运维安全边际）。
方案验收提醒：无论选择哪种模式，在架构方案交付时都需要书面承诺“租户恢复时间（RTO）”。对于 Database 模式，可以承诺 1 小时内恢复单个租户；对于 Schema 模式，必须明确告知恢复操作会导致实例级别的读写阻塞，并需要在设计中预留逻辑恢复通道。