3. 医疗SaaS多租户架构模式选型

医疗SaaS平台的多租户架构选型，本质上是在“隔离强度”与“资源效率”之间寻找平衡点。医疗行业受《个人信息保护法》《数据安全法》及等保2.0约束，患者身份信息、诊疗记录、检验结果等属于敏感个人信息，一旦发生跨租户数据泄露，后果远高于普通商业SaaS。因此，多租户模式不能只按“省钱”来选，而要先确定每个租户数据的隔离边界，再评估运维复杂度与成本是否可接受。

三种主流多租户数据隔离模式

独立数据库（Database per Tenant）：每个租户拥有独立的数据库实例或独立物理库，连接串、账号、备份策略均按租户独立管理。租户A的查询在物理上不可能触达租户B的数据，隔离级别最高。适合三级医院、区域医疗集团、对数据主权有强要求的客户。代价是实例数量随租户线性增长，连接池、备份、升级、监控都要按租户维度展开。

共享数据库、独立Schema（Shared Database, Schema per Tenant）：所有租户共用一个数据库实例，但每个租户拥有独立Schema（如MySQL中可理解为独立database，PostgreSQL/Oracle中为独立schema）。表结构相同，数据按Schema隔离。它保留了较强的逻辑隔离，同时把实例级运维成本摊薄。适合中型诊所、连锁门诊、体检中心等租户数量中等、单租户数据量不大的场景。

共享数据库、共享Schema（Shared Database, Shared Schema）：所有租户共用同一套表，通过tenant_id字段区分数据行。隔离完全依赖应用层SQL过滤、行级安全策略或数据访问中间件。资源利用率最高、扩容最平滑，但一旦SQL漏写租户条件、缓存键未带租户标识、异步任务未传递租户上下文，就会发生越权读写。适合小微机构、互联网医疗轻量租户、SaaS试用版或标准化程度极高的业务模块。

隔离级别、成本与运维的真实权衡

隔离级别不是抽象概念，它直接决定“故障半径”和“合规举证方式”。独立数据库模式下，租户A的慢查询、锁等待、磁盘写满不会影响租户B，备份恢复可以按租户粒度执行，等保测评时也更容易界定边界。共享Schema模式下，一个租户的慢SQL可能拖垮整个实例，一次误删可能波及所有租户，因此必须配合资源组、SQL限流、租户级连接池和审计日志。

成本方面，独立数据库的实例费用、备份存储、连接数授权随租户数线性上升；共享库独立Schema的实例成本被摊薄，但Schema数量过多时，元数据管理、DDL变更、跨Schema统计会变复杂；共享库共享Schema的存储和计算利用率最高，但需要额外投入租户上下文传递、SQL拦截、缓存隔离、异步任务隔离等中间件能力，这部分研发与测试成本不能忽略。

运维维度上，独立数据库的升级需要逐租户执行，适合灰度但耗时长；共享Schema的升级一次完成，但风险集中，必须先在预发环境用多租户数据做回归。医疗业务还有一条硬约束：患者数据删除请求、数据导出请求、审计追溯请求，在共享Schema下都要靠tenant_id精确定位，任何遗漏都会造成合规风险。

选型决策矩阵

实际选型不建议“一刀切”，可以按租户等级、数据敏感度、业务模块三个维度组合。下面给出一个可直接用于评审的决策矩阵示例，其中评分1～5分，分数越高表示该模式在该维度越合适。

一个可落地的混合策略是：核心诊疗数据（患者主索引、电子病历、处方、检验结果）采用共享库独立Schema，保证逻辑隔离与合规可解释；平台级配置、字典、消息、日志等低敏感数据采用共享Schema，降低公共表维护成本；对三级医院或区域平台等战略租户，单独部署独立数据库，并在网关层做租户路由。这样既避免全部独立库带来的成本失控，也避免全部共享Schema带来的合规与故障风险。

落地时的关键检查点

• 租户上下文传递：HTTP请求头、JWT声明、线程变量、异步任务、消息队列、定时任务都必须携带tenant_id，并在数据访问层强制注入，禁止业务代码手写过滤条件。
• 连接与资源隔离：共享实例下按租户配置连接池上限、慢SQL阈值和并发限制，防止单租户打满数据库。
• DDL变更策略：独立Schema模式需批量执行并校验每个Schema版本一致；共享Schema模式需评估大表加字段的锁表时间，医疗业务应安排在低峰窗口。
• 审计与追溯：所有跨租户查询、数据导出、删除操作必须记录操作人、租户、时间、SQL指纹，满足等保与内部审计要求。
• 迁移预留：初期采用共享Schema的租户，一旦升级为战略客户，应能通过数据导出与Schema拆分迁移到独立库，避免架构锁死。

多租户选型没有绝对最优解，只有与租户结构、合规要求、团队运维能力匹配的解。把隔离级别、成本、运维三者的关系量化成矩阵，再结合混合部署策略，才能在医疗SaaS的长期演进中既守住安全底线，又保持商业可持续性。