视图无法直接使用CURRENT_USER_ID()等动态函数，需借助会话变量（如PostgreSQL的current_setting）或行级安全策略（RLS）实现租户隔离；MySQL缺乏原生支持，依赖中间件或严格应用层控制。
视图里怎么加 WHERE user_id = CURRENT_USER_ID() 这种动态条件
SQL 视图本身不支持运行时参数，CURRENT_USER_ID() 这类函数在标准 SQL（如 PostgreSQL、SQL Server）里并不存在，MySQL 也没有原生等价物。硬写进去会报错或查不到数据。
真正可行的做法是：用数据库角色或会话变量模拟“当前租户”，再让视图引用它。不同数据库策略不同：
- PostgreSQL：依赖
current_setting('app.user_id')，需提前用SET app.user_id = '123'设置会话级变量 - SQL Server：可用
SESSION_CONTEXT(N'user_id')，连接后执行sp_set_session_context - MySQL：没有安全的会话变量方案，不建议在视图里做租户过滤，更适合用应用层预拼 WHERE 或代理层改写
示例（PostgreSQL）：
CREATE VIEW tenant_orders AS
SELECT * FROM orders
WHERE user_id = current_setting('app.user_id', true)::bigint;注意 true 表示缺失时不报错，返回 NULL —— 这会导致全表无结果，得靠应用确保先 SET。
为什么不能直接在视图里用 user_id = CURRENT_USER
CURRENT_USER 返回的是数据库登录用户（如 'app_user'@'%' ），不是业务系统的租户 ID。它和你的 users 表里的 id 字段完全无关，类型也不匹配，强行比较等于永远为 false。
常见错误现象：
- 查询返回空结果，但确认数据存在
- 日志里看到
ERROR: operator does not exist: integer = name（类型强制失败） - 视图能建成功，但一查就报
invalid input syntax for integer
根本原因：把认证身份（DB 用户）和业务身份（租户 ID）混为一谈。二者必须由应用层显式传递并绑定到会话上下文。
视图 + 行级安全策略（RLS）比纯视图更可靠吗
是的，PostgreSQL 的 RLS 是更推荐的方案，它比视图更底层、不可绕过，且权限检查发生在执行计划生成前。
关键区别：
- 视图只是封装 SELECT，用户仍可绕过它直接查基表（除非撤掉基表权限）
- RLS 策略作用于基表，即使用户写
SELECT * FROM orders也会自动加上user_id = current_setting(...) - RLS 支持
USING（SELECT 过滤）和WITH CHECK（INSERT/UPDATE 校验），天然防越权写入
启用 RLS 后，你甚至可以不用视图，直接授权用户查基表：
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON orders
USING (user_id = current_setting('app.user_id', true)::bigint);记得用 GRANT SELECT ON orders TO app_user，别再给视图授权。
MySQL 用户真没法用视图做租户隔离？
不能依赖视图本身，但可以用变通方式降低风险：
- 禁止用户直连生产库，所有请求走中间件（如 ProxySQL、ShardingSphere），由中间件注入
WHERE user_id = ? - 如果必须用 MySQL 视图，只能靠应用层严格约定：所有查询都走视图，且连接池每次获取连接后立即执行
SET @tenant_id = 123，然后视图里写WHERE user_id = @tenant_id - 但要注意：
@tenant_id是会话变量，不会跨连接复用；若连接被复用而未重置，会导致租户数据泄露
这种方案脆弱点在于：一旦某次查询忘了 SET，或用了连接池里的脏连接，隔离就失效。比起 PostgreSQL 的 RLS 或 SQL Server 的 SESSION_CONTEXT，MySQL 缺少原生、原子的租户上下文支持，这是架构上绕不开的限制。
最易被忽略的一点：租户字段索引是否覆盖了 user_id？没有的话，哪怕逻辑正确，每个租户查的都是全表扫描。别只盯着“能不能过滤”，先看“过滤之后快不快”。
