视图无法动态过滤租户数据，应改用行级安全策略（rls）或内联表值函数（tvf）；mysql需应用层拼where或存储过程；索引、分区与统计信息必须协同优化以保障隔离与性能。
视图里硬编码 WHERE user_id = CURRENT_USER_ID() 不行
直接在视图定义里写死某个 user_id 值，或者依赖非标准函数如 CURRENT_USER_ID()（MySQL 没这函数，PostgreSQL 是 current_setting('app.user_id')，SQL Server 是 SESSION_CONTEXT()），会导致视图无法复用或报错。视图是预编译对象，不支持运行时参数，也不能调用会话级变量（除非数据库明确支持且已配置）。
可行路径只有两条：一是用行级安全策略（RLS），二是把过滤逻辑下推到查询端——而后者才是多数场景下真正可控、可审计的做法。
- PostgreSQL 10+ 支持原生 RLS，可用
CREATE POLICY绑定到视图底层表 - MySQL 8.0+ 无 RLS，必须靠应用层拼
WHERE或用存储过程包装 - SQL Server 可用
SECURITY_POLICY+ 内联表值函数实现租户过滤，但视图本身不能含参数
用内联表值函数（TVF）替代视图更灵活
在 SQL Server 或 PostgreSQL 中，把“带租户过滤的逻辑”封装成内联 TVF，比视图更合适。它接受 @tenant_id 或 $1 参数，执行时动态注入，计划可重用，语义也清晰。
例如 PostgreSQL：
CREATE OR REPLACE FUNCTION tenant_orders(tenant_id UUID) RETURNS TABLE(id BIGINT, amount NUMERIC, created_at TIMESTAMPTZ) AS $$ SELECT id, amount, created_at FROM orders WHERE orders.tenant_id = $1; $$ LANGUAGE sql STABLE;
调用时：SELECT * FROM tenant_orders('a1b2c3...');
- 避免视图无法传参的硬伤
- 函数体仍是纯 SQL，不影响查询优化器下推条件
- 比起视图，更容易做权限控制（比如只授予用户执行该函数的权限）
MySQL 下只能靠应用层拼 WHERE 或用 PREPARE
MySQL 视图不支持参数，也没有 RLS，SESSION_CONTEXT 类机制也不存在。硬要在视图里“隔离”，唯一勉强可行的是用 USER() 解析用户名模拟租户，但极其脆弱：一旦账号共享、连接池复用或使用代理用户就失效。
更现实的做法是：
- 视图只做字段裁剪和关联简化，例如
CREATE VIEW active_orders AS SELECT o.id, o.amount, c.name FROM orders o JOIN customers c ON o.customer_id = c.id - 所有查询必须显式加
WHERE tenant_id = ?，由 ORM 或 DAO 层强制拦截注入 - 若真要服务端控制，可用存储过程 +
PREPARE/EXECUTE动态拼接，但会丢失查询计划缓存优势
别忽略索引和统计信息的影响
即使你成功让每条查询都带上 tenant_id，如果底层表没在 tenant_id 上建索引，或者没做分区，性能照样崩。尤其当租户数据量差异大时，优化器可能因统计信息不准选错执行计划。
- 复合索引优先考虑
(tenant_id, created_at)这类高频过滤+排序组合 - PostgreSQL 可对
tenant_id做列表分区；MySQL 8.0+ 支持 LIST COLUMNS 分区，但需确保tenant_id是整型或枚举化 ID - 定期执行
ANALYZE TABLE或VACUUM ANALYZE，否则租户 A 的统计信息可能误导租户 B 的查询计划
最麻烦的不是写不出带租户过滤的 SQL，而是让每个租户的查询既隔离又高效——这要求索引、分区、统计信息、连接上下文全部对齐，漏掉任意一环，隔离就只剩逻辑幻觉。
