用户能查视图却不能查基础表，是因为视图权限与基表权限相互独立、需分别显式授予，数据库仅校验当前访问对象的权限，不自动继承或推导；即使拥有视图SELECT权，若未被授予对应基表权限（或函数EXECUTE权、跨库USAGE权等），查询仍会因权限链断裂而失败。
用户能查视图却不能查基础表，是因为权限控制粒度不同：视图权限和基表权限是独立授予的，数据库只检查你对“当前对象”的权限，不自动向上或向下推导。
视图权限 ≠ 基表权限
数据库不会因为你有视图的 SELECT 权限，就自动给你它依赖的基表权限。反过来，哪怕你对基表有全权，没被单独授予权限，照样不能查视图（除非用 WITH CHECK OPTION 或者 schema owner 身份）。
- 视图创建者可以用
GRANT SELECT ON view_name TO user单独授权，这条语句不涉及任何基表 - 基表权限需显式授予：
GRANT SELECT ON base_table TO user，否则即使视图能跑通，也可能在某些场景下失败（比如 SQL Server 中启用VIEW DEFINITION限制时） - MySQL 8.0+ 支持列级权限，但视图里若引用了你没权限的列（如
salary），查询该视图时那一列会返回NULL，而不是报错——容易误判为“数据为空”
视图可能绕过基表权限限制
这是视图最常被用于安全隔离的机制：通过只暴露部分字段或加过滤条件，让低权限用户看不到敏感数据，也不需要给他们碰原始表的机会。
- 例如：给客服人员建视图
v_customer_public，只选id,name,phone，过滤掉credit_score和address_detail - 再执行
GRANT SELECT ON v_customer_public TO 'cs_user'@'%'，这个用户就能查视图，但查不到customers表本身 - 注意：如果视图定义里用了函数（如
ENCRYPT()）、子查询或 JOIN 多张表，而用户只对其中一张有权限，查询仍会失败——权限检查发生在执行时，逐表验证
常见报错其实是权限链断裂
不是“能查视图就一定没问题”，而是错误可能延迟暴露。典型现象包括：
- SQL Server 报错
The SELECT permission was denied on the object 'xxx', database 'yyy', schema 'zzz'—— 说明视图里某张基表你没权限 - MySQL 报错
SELECT command denied to user 'u'@'h' for table 't'—— 视图定义中直接引用了你无权访问的表t - PostgreSQL 报错
permission denied for relation xxx—— 同样是基表缺失权限，且不因视图存在而豁免 - 更隐蔽的情况：视图里调用了自定义函数（UDF），而你没有对该函数的
EXECUTE权限，也会中断查询
如何快速定位是哪张表卡住的
别靠猜，直接拆解视图定义去试：
- 用
SHOW CREATE VIEW view_name（MySQL）或pg_get_viewdef('view_name')（PostgreSQL）拿到原始 SQL - 把里面的
FROM和JOIN涉及的所有表、视图、函数列出来 - 挨个执行
SELECT 1 FROM table_name LIMIT 1，看哪个报权限错 - SQL Server 可用
SELECT * FROM sys.database_permissions WHERE grantee_principal_id = USER_ID('username')查当前用户所有已授予权限
真正容易被忽略的是：视图可以跨 schema、跨数据库甚至跨实例（链接服务器），而权限必须在每个目标对象上单独配置；少一个 GRANT，整个链就断在那儿，不报语法错，只静默失败或抛出权限异常。
