视图本身不自动实现行级隔离，必须配合WHERE条件和上下文变量；它仅是保存的查询语句，无执行时身份逻辑，需嵌入如current_user()等动态过滤条件，并严格控制基表权限，否则易被绕过。
视图本身不自动实现行级隔离，必须配合 WHERE 条件和上下文变量
SQL 视图（VIEW）只是保存的查询语句，不带执行时的身份或权限逻辑。直接创建一个通用视图，比如 CREATE VIEW user_orders AS SELECT * FROM orders，所有用户查到的都是全部数据——这根本不是行级隔离。真正起作用的是在视图定义里嵌入动态过滤条件，且该条件需依赖当前会话可获取的上下文信息，例如当前登录用户 ID。
常见做法是把用户标识（如 current_user()、session_user() 或自定义函数如 get_current_user_id()）作为过滤依据。但注意：不同数据库对“运行时变量”的支持差异很大，PostgreSQL 支持 current_user 和 session_user，MySQL 8.0+ 才支持 USER() 或 SESSION_USER()，而 SQL Server 需依赖 ORIGINAL_LOGIN() 或上下文字段。
- PostgreSQL 示例：
CREATE VIEW my_orders AS SELECT * FROM orders WHERE user_id = current_user::int;
（假设current_user返回用户名字符串，需类型转换） - MySQL 示例（需确保函数存在）：
CREATE VIEW my_orders AS SELECT * FROM orders WHERE user_id = (SELECT id FROM users WHERE username = USER());
- 避免硬编码：不要写成
WHERE user_id = 123，否则所有用户都看到同一个人的数据
权限控制必须显式授予视图，而非底层表
即使视图里写了 WHERE user_id = current_user_id，如果用户仍被直接授予了底层 orders 表的 SELECT 权限，他就能绕过视图直接查全量数据。行级隔离生效的前提是：只给用户 SELECT 视图的权限，同时收回其对基表的任何直接访问权。
- PostgreSQL 中执行：
REVOKE SELECT ON orders FROM app_user;<br>GRANT SELECT ON my_orders TO app_user;
- MySQL 中类似：
REVOKE SELECT ON mydb.orders FROM 'app_user'@'%';<br>GRANT SELECT ON mydb.my_orders TO 'app_user'@'%';
- 验证是否生效：用目标用户连接后执行
SELECT * FROM orders应报错ERROR 1142 (42000): SELECT command denied，而SELECT * FROM my_orders可正常返回结果
视图性能隐患：别让 WHERE 条件变成全表扫描
如果视图中依赖的过滤字段（如 user_id）没有索引，每次查询视图都会触发全表扫描——尤其当 orders 表有百万行时，响应可能从毫秒级变成秒级。这不是视图本身的锅，而是缺少基础优化。
- 检查索引是否存在：
SELECT * FROM pg_indexes WHERE tablename = 'orders' AND indexdef LIKE '%user_id%';（PostgreSQL） - 补建索引（以 PostgreSQL 为例）：
CREATE INDEX CONCURRENTLY idx_orders_user_id ON orders (user_id);
- 避免在 WHERE 中对字段做函数转换，例如
WHERE CAST(user_id AS TEXT) = current_user会导致索引失效；应统一数据类型，让user_id和变量类型一致
替代方案更可靠：策略（Policy）比视图更适合 RLS 场景
如果你用的是 PostgreSQL 9.5+，原生的行级安全策略（Row Level Security, RLS）比视图更干净、更可控。它直接绑定在表上，自动应用于所有对该表的查询（包括通过视图、函数、应用代码发起的），无需重写每个视图，也不怕用户绕过视图直接查表——只要开启 RLS 并设置策略，权限就生效。
- 启用 RLS：
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
- 添加策略：
CREATE POLICY user_order_policy ON orders<br>FOR SELECT USING (user_id = current_user::int);
- 关键区别：RLS 是强制性的，而视图是“建议性”的——用户可以不查视图；RLS 还支持 INSERT/UPDATE/DELETE 策略，视图做不到
视图适合简单、静态的隔离场景，但一旦涉及多角色、多租户或需要写操作控制，RLS 或应用层拦截才是实际能落地的选择。别低估策略规则里 USING 和 WITH CHECK 的语义差异，漏掉后者可能导致用户插入他人数据。
