多租户sql数据库隔离核心是数据可见性控制与操作权限边界划定，需在数据库层落实：通过tenant_id字段+行级安全策略（RLS）实现物理隔离，按租户分角色并遵循最小权限原则，连接池强绑定租户上下文，定期审计与脱敏测试保障安全。
多租户场景下，SQL数据库的隔离核心在于“数据可见性控制”和“操作权限边界划定”，不能只靠应用层过滤，必须在数据库层落实。共享模式（Shared database, Shared Schema）成本低、运维简单，但权限配置稍有疏忽就容易越权访问。
租户标识字段 + 行级安全策略（RLS）
在每张业务表中增加 tenant_id 字段（非空、索引），作为租户隔离的物理锚点。启用数据库原生行级安全（如 postgresql 的 RLS、SQL Server 的 Row-Level Security、mysql 8.0+ 可用视图+DEFINER 模拟），为每个租户角色绑定策略，自动注入 WHERE tenant_id = current_tenant_id() 条件。
- PostgreSQL 示例：创建策略
CREATE POLICY tenant_isolation ON orders for ALL using (tenant_id = current_setting('app.tenant_id')); - 确保应用连接时通过
SET app.tenant_id = 't123';显式声明当前租户上下文 - 禁用超级用户直连生产库，避免绕过 RLS
按租户分角色 + 最小权限原则
不复用 public 角色或 db_owner 权限。为每个租户创建独立数据库角色（如 role_tenant_a），仅授予其所属租户数据的 select/INSERT/UPDATE/delete 权限，且限制在带 tenant_id 过滤的视图或表上。
- 禁止跨租户 GRANT（如
GRANT SELECT ON orders TO role_tenant_b;） - 敏感操作（如 DROP table、TRUNCATE、EXECUTE PROCEDURE）一律拒绝，除非经审批开通临时会话级权限
- 使用视图封装逻辑：如
CREATE VIEW v_orders AS SELECT * FROM orders WHERE tenant_id = current_tenant_id();，再对视图授权
连接池与会话变量强绑定
租户身份不能依赖应用传参拼接 SQL（易 SQL 注入），也不能靠应用内存缓存租户 ID。必须由连接池（如 PgBouncer、HikariCP 配合拦截器）在建连后立即执行 SET 命令注入租户上下文，并校验该变量是否已设置且合法。
- 数据库侧可加检查函数：如 PostgreSQL 中定义
current_tenant_id()，内部校验current_setting('app.tenant_id', true)是否存在且匹配白名单 - 连接归还池前自动执行
RESET app.tenant_id，防止连接复用导致上下文污染 - 审计日志中记录每次查询的 session_user + app.tenant_id，便于追溯越权行为
定期权限巡检与租户数据脱敏测试
自动化脚本每月扫描：哪些角色拥有跨 tenant_id 的显式权限？是否存在未启用 RLS 的核心表？是否有视图未加 tenant_id 过滤？同时模拟租户 A 的账号，尝试访问租户 B 的接口或直连查询，验证是否返回空结果或报错。
- 用 SQL 快速检测：
SELECT table_name FROM information_schema.role_table_grants WHERE grantee = 'role_tenant_a' AND table_name IN ('orders','users'); - 测试用例应覆盖 JOIN 场景（如订单+用户表联查），确认关联字段也受 tenant_id 约束
- 开发环境启用 log_statement = ‘all’ 并过滤含 tenant_id 的执行计划，确认无全表扫描漏过滤
基本上就这些。共享模式不是妥协，而是把隔离逻辑从代码里“请进数据库”，靠机制而不是靠人盯。关键在 tenant_id 全链路贯穿、RLS 默认开启、权限按租户原子化分配——不复杂但容易忽略细节。