数据库隔离核心是数据不越界、权限不越权、查询不串扰；按实例、Schema、行三级方案需依业务敏感度等合理选择：实例级最安全但成本高，Schema级主流平衡，行级适合大规模低成本场景，且权限控制必须同步落地。
多租户场景下，数据库隔离的核心目标是：数据不越界、权限不越权、查询不串扰。关键不在“用哪种方案”，而在于根据业务敏感度、租户规模、运维能力做合理取舍。
按数据库实例隔离（最高安全等级）
为每个租户分配独立的数据库实例（甚至独立服务器），物理层面完全隔离。适合金融、政务等强合规场景。
- 优点：租户间零干扰，备份恢复、扩缩容、SQL审计均可独立操作
- 缺点：资源利用率低，实例管理成本高，需自动化运维平台支撑
- 建议：租户数少于50、单租户数据量大或SLA要求极高时优先考虑
按数据库Schema隔离（主流平衡方案）
共享同一数据库实例，但每个租户拥有独立Schema（如tenant_a、tenant_b），表结构一致，数据物理分离。
- 应用层需在连接后执行SET search_path TO tenant_x，或显式指定tenant_x.users
- 配合行级安全策略（如PostgreSQL的RLS）可进一步防御误查
- 注意避免跨Schema的JOIN或DDL操作，迁移脚本需支持Schema动态替换
按数据行隔离（租户数多、成本敏感型）
所有租户共用同一套表结构，在每张业务表中增加tenant_id字段，所有DML/SELECT必须带WHERE tenant_id = ?条件。
- 必须依赖中间件（如ShardingSphere）或ORM框架（如MyBatis拦截器）自动注入tenant_id，禁止应用直写SQL
- 索引需包含tenant_id（如(tenant_id, order_no)），否则查询性能急剧下降
- 高风险点：DBA手工运维、历史数据迁移、报表类宽表易漏tenant_id过滤
权限与访问控制必须同步落地
隔离策略再严密，若账号权限设计不当，依然可能被绕过。
- 禁止使用root或db_owner类超级账号连接应用；应为每个租户创建专用数据库用户
- Schema级隔离时，用户只授予对应Schema的USAGE + SELECT/INSERT/UPDATE权限，禁用CREATE权限
- 行级隔离时，即使租户用户能连通全库，也应通过视图（VIEW）或存储过程封装业务逻辑，隐藏底层tenant_id细节
