SQL Server中视图权限必须显式授予，不能继承基表权限；需执行GRANT SELECT ON [schema].[view_name] TO [user]，若视图调用函数或跨库引用，还需额外授予EXECUTE或目标库SELECT权限。
SQL Server 中视图权限必须显式授予，不能靠基表权限继承
直接给用户 SELECT 权限到基表，不代表他们能查视图——哪怕视图只查那一张表。SQL Server 默认不继承，必须单独执行 GRANT SELECT ON [schema].[view_name] TO [user]。
常见错误现象：用户执行 SELECT * FROM v_sales_summary 报错 The SELECT permission was denied on the object，但查基表却正常。这时候大概率是漏授了视图本身权限。
- 如果视图定义里调用了自定义函数（如
dbo.fn_calc_margin()），还得额外GRANT EXECUTE ON dbo.fn_calc_margin TO [user] - 若视图跨库引用（如
OtherDB.dbo.Orders），目标库中该用户也得有对应SELECT权限，不能只在当前库操作 - 避免用
db_datareader角色批量放权，它会绕过视图级控制，让精细权限设计失效
PostgreSQL 视图权限受 security_barrier 和 RLS 影响，不是授了 SELECT 就万事大吉
即使你已 GRANT SELECT ON v_customers TO analyst，查询仍可能返回空结果或报错，原因常出在底层行级安全（RLS）或函数安全性上。
PostgreSQL 默认对普通视图不启用安全屏障，而带 LEAKPROOF 函数的视图才触发 security_barrier 行为。非 LEAKPROOF 函数（比如自定义全文检索函数）可能导致敏感数据“泄露”或被策略拦截。
- 建视图时加
WITH (security_barrier = true)（9.5+ 支持），强制启用安全屏障 - 检查函数是否标记为
LEAKPROOF：SELECT proleakproof FROM pg_proc WHERE proname = 'your_func'；否则换用内置函数（如to_tsvector('english', ...)） - 用
EXPLAIN (VERBOSE)看执行计划，确认是否出现Row Security Policy过滤——这说明 RLS 已介入，需同步调整策略或角色设置
MySQL 视图权限失效，八成是 DEFINER 账号挂了
MySQL 视图默认以 DEFINER 身份执行。一旦创建视图的账号被删、密码过期、或权限被回收，哪怕你已给调用者授了 SELECT 权限，查询也会失败，报错类似：View 'db.vw' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them。
- 建视图时显式指定稳定账号：
CREATE DEFINER = 'svc_view@%' VIEW v_orders AS ... - 用
SHOW CREATE VIEW v_orders查当前DEFINER，再用SELECT User,Host FROM mysql.user确认该账号存在且未锁定 - 别用
CURRENT_USER当DEFINER——它随调用者变化，容易导致权限上下文混乱 - 若必须用高权限
DEFINER，确保该账号拥有视图内所有对象（表、函数、库）的SELECT权限，而不仅是创建时有
所有数据库都存在的隐形坑：权限缓存与角色继承链断裂
授完权限后立刻测试失败？不是语法错，很可能是权限缓存没刷新。SQL Server 和 PostgreSQL 会缓存权限元数据，MySQL 在部分版本中也有类似行为。
另一个高频问题：你以为把用户加进了角色，就自动继承了视图权限，但实际因角色嵌套层级过深、或中间某层被 DENY 覆盖，导致最终无权。
- SQL Server 执行
EXEC sp_refreshview 'v_name'并重连客户端；PostgreSQL 可发NOTIFY或重启连接；MySQL 建议用FLUSH PRIVILEGES（仅当改了mysql系统表时） - 查权限是否生效，别只看单条
GRANT语句——用SELECT * FROM fn_my_permissions(NULL, 'DATABASE')（SQL Server）或SELECT * FROM pg_auth_members（PostgreSQL）验证完整继承链 -
DENY优先级永远高于GRANT，哪怕它在另一角色里；排查时重点扫sys.database_permissions或pg_default_acl里有没有隐藏的DENY记录
真正卡住权限落地的，往往不是授权语句写得对不对，而是 DEFINER 账号状态、security_barrier 开关、以及那个没人记得曾 DENY 过的中间角色。
