多租户隔离的四种模式：共享库共享表只是起点

SaaS 架构里，“多租户怎么做隔离”经常被简化成“共享数据库还是独立数据库”的二选一，但实际选型至少有三个维度：数据隔离、计算隔离和故障隔离。每个维度的取舍不同，组合出来的方案也完全不同。

共享库共享表是最常见的起点。所有租户的数据在同一张表里，用 tenant_id 区分。成本最低，运维最简单，扩容也最容易。代价是隔离性最弱：一个租户的慢查询可能拖慢所有人，一个租户的数据量暴涨会影响整张表的索引效率，权限控制完全依赖应用层的 WHERE tenant_id = ?，一次漏写就是数据泄露。适合早期产品、租户量不大、SLA 要求不高的场景。

共享库独立 schema 是中间档。每个租户一个 schema，表结构相同但数据物理分开。隔离性比共享表好，单个租户的索引和统计信息独立，备份和恢复可以按租户做。代价是 schema 数量随租户增长，数据库的连接数、元数据管理和迁移脚本的复杂度都会上升。适合租户数量可控、需要一定数据隔离但不想为每个租户维护独立实例的场景。

独立数据库是更强的隔离。每个租户一个数据库实例或至少一个独立数据库，数据、连接、资源都分开。一个租户的故障不会直接影响另一个，性能可预测性最好。代价是运维成本线性增长，连接池、备份、监控、升级都要按租户管理。适合租户数量有限、单租户数据敏感或 SLA 要求高的企业级产品。

混合模式在实践中很常见。大客户用独立数据库，中小客户共享库共享表；或者核心数据独立、非核心数据共享。混合模式的关键是路由层要统一，不能让业务代码到处判断“这个租户用哪种模式”。一个租户到存储的映射应该收敛到配置或元数据服务里，业务层只关心“按租户 ID 取数据”，不关心底层是哪种隔离。

选择隔离模式时，先问三个问题：租户数据是否涉及强合规要求（决定数据隔离下限）；单租户的负载是否可能影响其他租户（决定计算隔离需求）；故障时能不能接受“一个租户挂影响一片”（决定故障隔离级别）。三个问题的答案组合起来，比“共享还是独立”的二选一更接近真实需求。