4. 数据隔离模式全景对比：独立数据库、共享数据库独立Schema、共享库共享表、混合模式

4.1 模式概述与边界定义

多租户数据隔离的核心矛盾在于：隔离安全性与资源利用率之间的动态平衡。业界归纳出四种主流模式，每种模式划定了租户数据的逻辑与物理边界：

4.2 分层架构与组件职责

无论哪种模式，数据访问层均需插入租户路由中间件，该组件负责将租户标识解析为物理存储位置。下表给出各层关键职责：

4.3 数据流 / 控制流 / 信任链路

1. 数据流：租户操作 → 应用层SQL → 路由层读取元数据 → 执行层切换/加条件 → 存储层返回结果 → 应用层清理上下文。
2. 控制流：租户上下文注入（Filter/Interceptor）→ 数据源选择器根据tenant_id查映射表 → 建立连接/重写SQL → 执行并返回。
3. 信任链路：独立数据库 信任边界在数据库连接层面，数据库用户隔离；共享Schema 信任边界依赖Schema级权限；共享表 完全依赖应用层正确的tenant_id过滤，风险最高。

4.4 四模式内联SVG框架图

4.5 选型权衡关键点

• 收入 vs 成本：大客户（高合规要求）用独立DB，中小客户用共享Schema，免费层用共享表——这是混合模式最常见的落地形态。
• 租户数量级：低于100租户可全量独立，100～5000用共享Schema，超万级必须引入共享表以防止连接数爆炸。
• 隔离强度需求：金融、政务场景必须独立DB；企业级SaaS可接受Schema级；消费级SaaS可接受行级。
• 运维能力：独立DB需要自动化创建/备份/监控脚本，否则DBA将成为瓶颈。

4.6 风险点

4.7 落地步骤

1. 步骤一：租户分级 建立租户等级（免费/标准/专业/企业），确定各等级采用的隔离模式。
2. 步骤二：元数据设计 创建租户配置表，存储tenant_id、模式类型、数据库连接串、Schema名称。
3. 步骤三：路由中间件开发 实现DatasourceRouter接口，根据租户配置动态选择数据源/重写SQL。
4. 步骤四：隔离验证 开发自动化测试用例，模拟跨租户访问并断言阻断。
5. 步骤五：数据迁移工具 对于从共享表升级为独立DB的租户，提供不停机迁移脚本。
6. 步骤六：监控与告警 采集各数据源连接数、QPS、延迟，当单库租户数接近阈值时触发扩容建议。

4.8 验收标准