视图本身不控制字段权限，仅实现字段可见性隔离；真正实现列级安全需回收基表SELECT权限并单独授予视图SELECT权限，缺一不可。
视图本身不控制字段权限，只控制字段可见性
创建视图时写 SELECT id, name FROM users，用户查这个视图就看不到 salary 或 ssn，但这只是“看不见”，不是“不能看”。只要用户有基表的 SELECT 权限，执行 SELECT salary FROM users 就立刻绕过视图暴露敏感列。
真正起作用的是权限组合：先回收基表访问权，再单独授予视图权限。漏掉任一环，字段隔离就失效。
- PostgreSQL 报错
permission denied for relation users，大概率是忘了REVOKE SELECT ON users FROM app_user - MySQL 8.0+ 用户若已被授
SELECT ON mydb.users，哪怕你建了v_user_safe，也完全无效 - SQL Server 视图定义不会自动同步基表结构变更；新增列后没重跑
ALTER VIEW，可能因列数不匹配直接报错
必须显式列出字段，禁用 SELECT *
SELECT * 在视图里是高危操作：基表加新列后，视图返回列数变多，下游应用（尤其是 JDBC 或 ORM）可能抛 SQLFeatureNotSupportedException；更严重的是，新加的敏感字段（比如 password_hash）会直接暴露。
正确做法是逐个写出需要暴露的列名，例如：
CREATE VIEW v_user_basic AS SELECT user_id, username, email, created_at FROM users;
- PostgreSQL 和 MySQL 8.0+ 都支持这种显式投影，但 SQL Server 视图不会自动适配基表变更，必须手动维护
- 字段顺序、别名、类型要明确——某些客户端（如 pgAdmin）依赖元数据，缺失会导致解析失败
- 避免在视图里套脱敏函数（如
MD5(email)），这类表达式会让索引失效，且逻辑可被pg_get_viewdef()或SHOW CREATE VIEW查看
不同数据库对视图执行权限模型差异极大
谁的权限生效，决定了用户能否绕过视图——这不是语法问题，而是执行模型问题。
- PostgreSQL 默认走
SECURITY INVOKER（调用者权限），意味着用户仍需基表权限；要绕过，得显式声明CREATE VIEW ... WITH (security_invoker = false)或后续ALTER VIEW ... SET (security_invoker = false) - MySQL 默认是
DEFINER执行，但必须确保DEFINER='admin'@'%'这个账号真实存在且未被删，否则报错ERROR 1449 - SQL Server 默认按
SCHEMABINDING创建的视图能防基表结构误改，但不增强权限隔离能力
跨库迁移或统一运维时，不能假设行为一致。MySQL 的 SQL SECURITY DEFINER 和 PostgreSQL 的 security_invoker = false 是等效动作，但语法和依赖完全不同。
列级授权（GRANT SELECT(col1,col2)）不是替代方案
MySQL 8.0+ 和 SQL Server 支持按列授 SELECT 权限，例如：
GRANT SELECT (user_id, username) ON users TO 'reporter'@'%';
但注意这不等于安全隔离：
- 语法必须严格：
GRANT SELECT ON users(user_id, username)是错的，括号必须紧贴列名前 - 列权限和表权限叠加生效——如果用户已有整表
SELECT，再授部分列不会撤销其他列访问权 - MySQL 5.7 及更早版本不支持该语法，执行直接报
ERROR 1064 - PostgreSQL 列授权对
UPDATE无效，且无法与行级策略（RLS）无缝协同
最稳妥的路径仍是：视图 + 显式字段列表 + 基表权限回收 + 视图单独授权。复杂点在于每个环节都得验证，比如 USAGE 权限是否赋予了对应 schema，DEFINER 是否有效，以及角色是否激活——缺一不可，且错误往往只在运行时才暴露。
