最稳妥做法是在视图定义中直接写 WHERE tenant_id = CURRENT_SETTING('app.current_tenant')，配合应用层每次请求前执行 SET app.current_tenant = 't123'，确保租户数据隔离；须避免用 CURRENT_USER、裸引用视图、缺失索引或绕过视图直查基表。
视图里怎么加租户ID过滤条件
直接在视图定义中写死 WHERE tenant_id = CURRENT_SETTING('app.current_tenant') 是最常用也最稳妥的做法。PostgreSQL 的 CURRENT_SETTING 能读取会话级配置，配合应用层每次请求前执行 SET app.current_tenant = 't123'，就能让同一张视图对不同租户返回不同数据。
常见错误是试图用 CURRENT_USER 或 SESSION_USER 代替租户标识——它们对应数据库用户，不是业务租户，多租户场景下几乎没用。
- 必须确保应用在每个新连接或事务开始时都显式设置
app.current_tenant，否则查询可能返回空或全量数据 - 不建议用函数（如
get_current_tenant_id()）封装该逻辑，除非你已为该函数加上VOLATILE并确认它不会被优化掉 - MySQL 用户注意：没有等价的会话变量自动注入机制，得改用
WHERE tenant_id = @current_tenant，且每次查询前必须手动SET @current_tenant = 't123'
视图能否嵌套并保持租户隔离
可以，但要注意依赖视图的 WHERE 条件不会自动“穿透”。比如视图 v_orders 已含 tenant_id 过滤，再基于它创建 v_orders_summary，后者仍需显式保留或重申租户过滤，否则 PostgreSQL 可能因优化将外层过滤提前剔除。
典型翻车现场：定义 v_orders_summary AS SELECT COUNT(*) FROM v_orders GROUP BY status，结果发现统计值跨租户——因为 v_orders 的过滤条件在嵌套中被当作“无关谓词”优化掉了。
- 安全做法是在所有中间视图里重复写
WHERE tenant_id = CURRENT_SETTING('app.current_tenant') - 避免用
CREATE VIEW ... AS SELECT * FROM v_base这类裸引用，务必展开字段并带上租户条件 - 如果用物化视图，
tenant_id条件必须固化在查询中，不能依赖运行时变量（物化视图不支持会话变量）
WHERE条件隔离 vs 行级安全策略（RLS）选哪个
优先用 RLS，视图方式只是兼容性兜底。RLS 是 PostgreSQL 原生支持的租户隔离机制，规则绑定在表上，对所有访问路径（包括直接查基表、通过视图、甚至通过函数）都生效，而视图只能约束走它的那条路径。
错误认知：“用了视图就安全了”——只要有人绕过视图直查 orders 表，租户数据就裸奔。RLS 能堵住这个口子。
- 启用 RLS 后，必须为每个租户角色（如
tenant_t123）单独启用策略：ALTER TABLE orders ENABLE ROW LEVEL SECURITY，再CREATE POLICY tenant_isolation ON orders USING (tenant_id = current_setting('app.current_tenant')) - 视图方案适合无法修改数据库权限模型的老系统；RLS 要求你有
CREATEROLE或表属主权限，上线前得评估权限变更成本 - MySQL / SQL Server 用户别硬套：它们没有 RLS，视图 + 应用层强约束是唯一可行路径
性能影响：WHERE条件会不会拖慢查询
只要 tenant_id 字段上有索引，且查询计划显示走了 Index Scan 或 Index Only Scan，性能基本无感。问题出在两类情况：索引缺失，或者租户条件被优化器误判为“低选择性”而弃用索引。
一个容易被忽略的坑：当视图里写 WHERE tenant_id = 't123'（字面量），PostgreSQL 会缓存执行计划，换租户后查不到数据或查错——所以必须用 CURRENT_SETTING 这类运行时函数，强制每次重编译计划。
- 检查执行计划是否真的用了索引：
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM v_orders LIMIT 10 - 避免在
tenant_id上建函数索引（如LOWER(tenant_id)），RLS 和视图里的等值匹配会失效 - 如果租户数据量极不均衡（比如大租户占 90% 数据），考虑对高频租户单独分区，否则索引扫描仍可能扫过多块
租户隔离不是加个 WHERE 就完事的事，关键在变量传递是否可靠、索引是否真生效、以及有没有人能绕过你的视图去碰基表。
