根本原因是视图权限与基表权限完全解耦，数据库独立校验二者，无继承关系；查视图只验视图权限，查基表只验基表权限，即使有基表权限未授视图仍不可查，反之亦然。
用户能查视图却不能查原表，根本原因不是权限“漏授”，而是数据库压根不把视图权限和基表权限当一回事——它们是两套独立校验的体系，中间没有自动继承、没有隐式兜底。
视图权限与基表权限完全解耦
数据库只检查你对「当前正在访问的对象」有没有权限。查 SELECT * FROM my_view，它只看你有没有 SELECT ON my_view；查 SELECT * FROM base_table，才去核验 SELECT ON base_table。两者之间没有任何逻辑关联。
- 即使你对
base_table有SELECT权限，没被单独授予my_view，照样查不了视图 - 反过来，哪怕你只有
my_view的SELECT权限，且对base_table完全无权，只要视图定义合法、执行上下文正确，查询仍能成功 - MySQL 中若视图是
SQL SECURITY INVOKER（默认），而用户又没基表权限，就会直接报ERROR 1142；必须改成DEFINER模式并确保定义者账号存在且有基表权限
报错信息暴露的是哪一层失败
错误不是随机发生的，它精准指向权限链中断的具体位置：
- MySQL 报
SELECT command denied to user 'u'@'h' for table 't'→ 视图定义里引用了你无权访问的基表t - SQL Server 报
The SELECT permission was denied on the object 'xxx', database 'yyy', schema 'zzz'→ 视图依赖的某张表或函数，你没被授权 - PostgreSQL 报
permission denied for relation xxx→ 同样是基表缺失权限，且不会因视图存在而豁免 - 如果视图里调用了自定义函数（如
ENCRYPT()），你还得有对该函数的EXECUTE权限，否则也会卡住
MySQL 下实现“只看视图、不碰原表”的硬性条件
光 GRANT SELECT ON db.my_view TO 'u'@'%' 远远不够，必须同步完成三件事：
-
REVOKE SELECT ON db.* FROM 'u'@'%'—— 清掉库级所有表权限（包括基表和其它视图） -
REVOKE SHOW DATABASES ON *.* FROM 'u'@'%'—— 否则SHOW DATABASES会暴露其它库名，用户可尝试跨库探测 - 建视图时明确指定
SQL SECURITY DEFINER，且DEFINER账号（如'admin'@'localhost'）必须真实存在、主机匹配、且拥有基表SELECT权限
漏掉任意一项，所谓“隔离”就只是表面功夫。
容易被忽略的隐蔽失效点
最麻烦的不是报错，而是“看起来正常却实际失效”：
- 视图定义中用了列级权限未覆盖的字段（如
salary），查询时该列返回NULL，可能让应用误判为“数据为空”而非“权限不足” - 视图嵌套：上游视图如果是
INVOKER模式，下游即使设成DEFINER也救不回来 - 视图依赖的函数、存储过程或跨库对象（如
other_db.table），都需单独授USAGE或对应权限，缺一不可 -
SHOW CREATE VIEW my_view报错，说明视图元数据已损坏或引用了已被删的表/函数，此时权限再全也没用
真正难的不是写一条 GRANT，而是每次授权后都得连上去跑四条命令验证：SHOW DATABASES、SELECT * FROM information_schema.TABLES、SELECT * FROM my_view、SELECT * FROM base_table——少一条，你就没法确认隔离是否真成立。
