只读视图不能仅靠GRANT SELECT实现，因其仅授予基表读权限，无法隐藏敏感字段或行；必须通过显式列选择、行级WHERE过滤、SECURITY DEFINER模式及撤销基表直连权限来构建真正隔离的只读访问层。
只读视图为什么不能靠 GRANT SELECT 就完事
因为 GRANT SELECT 给的是对基表的读权限，用户拿到后仍可 SELECT * FROM users 看到所有字段，包括 password_hash、last_login_ip 这类敏感列。真正的权限降级，得从数据暴露面入手——用视图做“过滤层”，把不该看的列、不该见的行提前掐掉。
关键点在于：视图本身不带权限，它只是查询的封装；你必须 GRANT SELECT ON view_name TO user，且确保该用户对底层表**没有直接 SELECT 权限**，否则视图形同虚设。
- 创建视图前，先
REVOKE SELECT ON TABLE users FROM app_reader（如果之前误授过） - 视图定义里别用
*，显式列出需要的列，比如SELECT id, username, created_at FROM users - 若需行级过滤（如只让部门A看到本部门数据），在
WHERE中写死条件，例如WHERE dept = 'A'—— 注意这无法参数化，是静态过滤
CREATE VIEW 时容易忽略的 SECURITY 属性
PostgreSQL 和 SQL Server 支持 SECURITY DEFINER / SECURITY INVOKER，MySQL 8.0+ 也支持 SQL SECURITY。默认多数是 INVOKER，意味着视图执行时检查调用者对基表的权限 —— 这会绕过你的“只读隔离”设计。
正确做法是显式声明 SECURITY DEFINER（PostgreSQL/MySQL）或 WITH EXECUTE AS OWNER（SQL Server），让视图以定义者身份运行，从而只依赖定义者权限，不穿透查用户权限。
- PostgreSQL 示例：
CREATE VIEW v_users_public WITH (security_invoker = false) AS SELECT id, username FROM users;
- MySQL 示例：
CREATE ALGORITHM=MERGE SQL SECURITY DEFINER VIEW v_users_public AS SELECT id, username FROM users;
- 没声明时，某些数据库可能静默按
INVOKER处理，导致授权后仍报permission denied for table users
分发只读视图时，别把物化视图当普通视图用
物化视图（如 PostgreSQL 的 MATERIALIZED VIEW、Oracle 的 MV）本质是物理快照，刷新需额外权限（REFRESH），且数据非实时。如果你目标是“实时只读访问”，就别建物化视图 —— 它解决的是性能问题，不是权限问题。
更隐蔽的坑是：有些 DBA 为“防止基表被删”，给用户授予了对物化视图的 SELECT，却忘了物化视图依赖基表存在；一旦基表被 DDL 修改（如加列），物化视图可能失效，而错误信息常是模糊的 relation not found 或刷新失败。
- 确认需求是“实时”还是“准实时”：选普通视图 or 物化视图
- 若用物化视图，分发前必须确保用户有
SELECT权限，且 DBA 定期维护刷新策略 - 避免在视图中引用临时表、CTE 或未授权的函数（如
current_user()在DEFINER模式下返回定义者而非调用者）
跨 schema 分发时，search_path 和 qualified name 的冲突
在 PostgreSQL 中，如果视图定义里写了 SELECT * FROM users，而没加 schema 前缀，那么执行时依赖调用者的 search_path。若用户能连上多个 schema，且其中某个 schema 下恰好也有个 users 表，就可能查错数据 —— 这属于逻辑越权，比权限越权更难审计。
解决方案只有两个：要么在 CREATE VIEW 时强制用带 schema 的全名（如 public.users），要么在创建后用 ALTER VIEW ... SET (security_invoker = false) 锁定行为（PostgreSQL 15+）。
- 安全写法：
CREATE VIEW v_users_public AS SELECT id, username FROM public.users WHERE status = 'active';
- 别依赖
SET search_path TO public这类会话级设置来“兜底” - SQL Server 用户注意：视图中引用的表名若不含 schema（如
SELECT * FROM users），默认解析为dbo.users，但若用户 default schema 不是dbo，可能报错
复杂点往往不在语法，而在权限链路的每一环是否真正切断：视图定义是否封闭、执行上下文是否可控、分发路径是否排除了隐式访问通道。漏掉任意一环，只读承诺就只是纸面约定。
