2. 数据隔离模式

在多租户SaaS架构中，数据隔离模式决定了租户数据在存储层的物理与逻辑分离程度。选择哪种模式，直接影响系统的安全性、运维复杂度、资源利用率以及扩展能力。本节将深入剖析三种主流模式：独立数据库模式、共享数据库独立Schema模式、共享数据库共享表模式（行级隔离），并从多个维度进行对比。

2.1 三种模式核心概念与架构

三种模式在数据隔离粒度、资源隔离性、以及运维成本上存在显著差异。下图直观展示了三种模式的架构对比。

2.2 模式详解与对比

2.2.1 独立数据库模式

定义：每个租户独享一个独立的数据库实例。这是最严格的数据隔离方式，类似于传统单租户架构。

• 优点：数据隔离性最强，安全性最高；便于备份、恢复和迁移；可针对不同租户进行独立的性能调优。
• 缺点：资源利用率低，维护成本高；数据库连接数随租户数量线性增长，可能成为瓶颈；部署和升级复杂。
• 适用场景：金融、医疗等强监管行业；对数据安全有极高要求的大客户；租户数量较少但每个租户数据量大的场景。

2.2.2 共享数据库独立Schema模式

定义：多个租户共享同一个数据库实例，但每个租户拥有独立的Schema（如 MySQL 中的 Database，或 PostgreSQL 中的 Schema）。

• 优点：资源利用率高于独立数据库模式；逻辑隔离性较好，租户间数据互不可见；支持一定程度的租户级定制（如表结构微调）。
• 缺点：数据库实例故障会影响所有租户；跨租户查询复杂；Schema数量过多时，管理成本上升。
• 适用场景：中型SaaS应用；租户数量中等（几百到几千）；需要一定隔离性但希望控制成本。

2.2.3 共享数据库共享表模式（行级隔离）

定义：所有租户共享同一套表结构，通过表中的 tenant_id 字段来区分数据行。这是最经济的多租户模式。

• 优点：资源利用率最高，支持海量租户；运维简单，表结构统一；查询性能优化相对容易（如分区、索引）。
• 缺点：数据隔离性最弱，依赖应用层和SQL正确性；一旦出现SQL注入或逻辑漏洞，可能导致数据泄露；备份恢复粒度粗，无法单独恢复某个租户的数据。
• 适用场景：大规模SaaS平台（如CRM、协作工具）；租户数量巨大（数万至数百万）；对隔离性要求不高的通用场景。

2.3 三种模式核心维度对比表

2.4 行级隔离的SQL实现示例

在共享数据库共享表模式中，所有SQL查询必须强制携带 tenant_id 过滤条件。以下是一个典型的数据访问层实现示例：

-- 创建表时，必须包含 tenant_id 字段
CREATE TABLE orders (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    tenant_id VARCHAR(64) NOT NULL,
    order_number VARCHAR(128) NOT NULL,
    amount DECIMAL(10,2) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_tenant_order (tenant_id, order_number)
);

-- 查询时，必须通过 tenant_id 过滤
SELECT * FROM orders
WHERE tenant_id = 'tenant_abc123'
  AND created_at >= '2024-01-01';

-- 插入时，必须显式指定 tenant_id
INSERT INTO orders (tenant_id, order_number, amount)
VALUES ('tenant_abc123', 'ORD-2024-001', 299.99);

-- 更新/删除时，同样必须携带 tenant_id
UPDATE orders
SET amount = 349.99
WHERE id = 1001 AND tenant_id = 'tenant_abc123';

DELETE FROM orders
WHERE id = 1001 AND tenant_id = 'tenant_abc123';

2.5 模式选择决策流程

在实际项目中，选择哪种模式通常需要综合评估以下因素。下图提供了一个简化的决策流程。