SQL视图权限与可见性无关，必须显式授予SELECT权限，不能继承基表权限；MySQL中视图是独立对象，权限单独存储，需用GRANT SELECT ON db.view精确授权，且DEFINER失效或依赖损坏会导致非权限类错误。
SQL视图的可见性规则和权限是两回事
“可见性规则”指事务中能看到哪些行版本（比如 MVCC 快照决定哪条数据对当前 SELECT 可见），它和“权限”无关。权限控制的是“能不能执行 SELECT”，可见性控制的是“执行了 SELECT 之后看到什么数据”。很多 DBA 把 ERROR 1142（权限拒绝）和空结果（可见性过滤）混为一谈，结果花半天查 RLS 或快照，其实根本没授视图 SELECT 权限。
MySQL 视图权限不继承，必须显式 GRANT
哪怕你对 users 表有 SELECT，查 v_active_users 还是报错 ERROR 1142——因为 MySQL 不会把表权限自动映射到视图。视图是独立对象，权限记录在 mysql.tables_priv 中，和表权限分开存。
- 确认视图所在库：用
SELECT TABLE_SCHEMA FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_NAME = 'v_active_users' - 授予权限必须带库名：
GRANT SELECT ON `mydb`.`v_active_users` TO 'reporter'@'localhost' -
GRANT SELECT ON mydb.*不生效——它只覆盖表，不覆盖视图 - MySQL 8.0+ 通常不用
FLUSH PRIVILEGES，但旧版本建议执行
PostgreSQL 和 SQL Server 的权限穿透风险
它们允许用户绕过视图，直接查基表——只要账号对视图引用的任意一张源表有 SELECT 权，SELECT * FROM vw_orders 就能成功，SELECT * FROM orders 同样能成功。这不是 bug，是默认行为。
- 堵住元数据泄露：在 PostgreSQL 中
DENY VIEW DEFINITION不适用，改用REVOKE SELECT ON ALL TABLES IN SCHEMA public FROM role_name，再单独GRANT SELECT ON TABLE vw_orders TO role_name - SQL Server 要额外
DENY VIEW DEFINITION ON DATABASE::[mydb] TO [webuser]，否则 BI 工具连sys.tables都能枚举出来 - 嵌套视图要逐层检查：用
SELECT VIEW_DEFINITION提取所有依赖对象，再对每个对象运行SHOW GRANTS或sys.fn_my_permissions
DEFINER 模式下权限检查主体易被忽略
MySQL 默认用 SQL SECURITY DEFINER，意思是执行视图时检查的是创建者（如 'admin'@'localhost'）的权限，不是调用者的。如果这个 DEFINER 账号被删了或权限被回收，视图立刻失效，报错类似 definer/invoker of view lack rights to use them。
- 查定义方式：
SHOW CREATE VIEW v_active_users，看是否含DEFINER=`admin`@`localhost` - 修复方法：要么重建视图并指定有效 DEFINER，要么改成
SQL SECURITY INVOKER（但得同步给调用者授基表权限） - PostgreSQL 没 DEFINER 概念，但要注意 schema 的
USAGE权限——即使给了视图SELECT，若没USAGE ON SCHEMA public，照样报 permission denied
真正容易被忽略的是：权限补全后，视图底层若存在已删表、失效函数或跨库链接中断，执行时触发的不是权限错误，而是 ERROR 1356 或 permission denied for function ——这些错误看起来像权限问题，实际是依赖链断了。
