直接给视图授SELECT权限不够，还需检查SQL Server的基表REFERENCES/函数EXECUTE权限、PostgreSQL的security_barrier与LEAKPROOF函数、MySQL的DEFINER有效性及权限缓存刷新。
直接给视图授 SELECT 权限就行，但光执行 GRANT SELECT ON [schema].[view_name] TO [user] 往往不够——多数权限失效不是因为命令写错，而是漏掉了依赖项。
SQL Server：必须检查基表和函数的 REFERENCES/EXECUTE 权限
视图本身不存数据，SQL Server 不会自动继承底层对象权限。用户能查视图，前提是：对视图定义里所有基表有 REFERENCES 权限（尤其当视图含计算列、JOIN 或 UDF），对调用的函数有 EXECUTE 权限。
- 先跑
SELECT OBJECT_DEFINITION(OBJECT_ID('dbo.vw_sales_summary'))看视图定义，确认是否引用了函数（如dbo.fn_get_region_name()）或跨库对象（如OtherDB.dbo.Orders） - 若有自定义函数，补授：
GRANT EXECUTE ON dbo.fn_get_region_name TO [user] - 若跨库，目标库
OtherDB中也得执行：USE OtherDB; GRANT SELECT ON dbo.Orders TO [user] - 避免用
db_datareader角色——它绕过视图级控制，让GRANT SELECT ON VIEW形同虚设
PostgreSQL：security_barrier 和 LEAKPROOF 函数影响实际可查性
即使 GRANT SELECT ON vw_customers TO user1 成功，查询返回空或报错，大概率是安全屏障没生效，或用了非 LEAKPROOF 函数（比如自定义全文检索函数）。
- 建视图时显式加
WITH (security_barrier = true)（9.5+ 支持） - 查函数是否安全：
SELECT proleakproof FROM pg_proc WHERE proname = 'to_tsvector'；若为f，就不能用于带 RLS 的视图 - 用
EXPLAIN (VERBOSE) SELECT * FROM vw_customers看执行计划里有没有Row Security Policy过滤——有说明 RLS 意外拦截了
MySQL：DEFINER 失效比权限缺失更常见
报错 View 'db.vw' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them，基本不是权限问题，而是视图的 DEFINER 账号已删或无权。
- 查当前定义：
SHOW CREATE VIEW `vw_sales`，看DEFINER是谁 - 确认该账号存在：
SELECT User,Host FROM mysql.user WHERE User = 'admin' - 重建视图时优先用
DEFINER = CURRENT_USER，或指定一个长期存在的服务账号（如'svc_viewrunner'@'localhost'） - 如果必须用高权限
DEFINER，确保该账号对视图内所有表、函数都有SELECT权限，不能只靠创建者本人有权限
权限变更后查询仍失败？可能是缓存没刷新
连接池复用、长连接场景下，SQL Server 和 MySQL 都可能缓存权限检查结果，导致刚授完权却查不了。
- SQL Server：执行
DBCC FLUSHAUTHCACHE（需sysadmin权限）或让应用重连 - MySQL：执行
FLUSH PRIVILEGES（仅对mysql表直改有效），更可靠的是重启连接或等wait_timeout自然断开 - PostgreSQL：不需要手动刷新，但需注意
pg_hba.conf修改后要pg_ctl reload，否则新用户连不上
真正卡住人的从来不是那条 GRANT 语句，而是它背后那一串隐式依赖：函数权限、跨库账号、DEFINER 存活性、甚至连接生命周期。漏掉任意一环，权限就只是“看起来给了”。
