标准答案
- 行级隔离在共享表中加入 tenant_id，资源利用率高、运维简单，但每条读写都必须可靠注入租户条件和权限校验。
- 独立 Schema 能减少对象命名冲突和部分误操作影响，但迁移、连接管理和工具兼容仍需要统一治理。
- 独立数据库或集群提供更强的资源、备份和故障隔离，适合大客户、数据驻留或高合规场景，代价是运维和跨租户分析更复杂。
- 可以采用分层方案：大多数租户共享，小部分高价值或合规租户单独迁移。
- 无论选哪种物理方案，应用身份、查询构造、缓存 Key、对象存储路径和日志都必须携带并校验租户边界。
题目解析
隔离不是只在表里多一个 tenant_id。一次漏条件的 SQL、缓存 Key 缺少租户前缀、后台任务拿错上下文，都可能造成越权。物理隔离可以降低爆炸半径，却不能替代应用层授权。
选型要预留迁移路径。许多 SaaS 从共享表起步是合理的，但应尽早让路由、连接和数据访问层具备按租户选择存储位置的能力，避免大客户出现后只能停机搬迁。
常见误区
- 仅相信前端传来的 tenantId，而没有从认证上下文和资源归属再次校验。
- 所有租户共用一个无上限连接池，大租户高峰把小租户的请求全部挤掉。