视图查不了主因是DEFINER账号失效或无基表权限，非当前用户缺权限；MySQL报1142/1449需查DEFINER存在性及逐表授SELECT，SQL Server须单独授视图SELECT权限，Oracle需显式授被引用对象SELECT且角色权限编译时不生效。
视图查不了，大概率不是你当前账号缺 SELECT 权限，而是定义者（DEFINER）账号失效、权限不全，或安全模型没对齐——MySQL/SQL Server/Oracle 的排查路径完全不同，不能套用同一套操作。
MySQL 报 ERROR 1142 或 1449：先确认 DEFINER 是否存在且有基表 SELECT 权限
错误里出现 for table 'xxx'（不是视图名），基本就是 DEFINER 账号对某张底层表没 SELECT 权限；如果报 ERROR 1449: The user specified as a definer does not exist，说明定义者账号在 mysql.user 表里已经没了。
- 执行
SHOW CREATE VIEW view_name\G，看输出里的DEFINER和SQL SECURITY模式 - 用
SELECT User, Host FROM mysql.user WHERE User = 'definer_user' AND Host = 'host_part';确认账号是否存在 - 若存在，运行
SHOW GRANTS FOR 'definer_user'@'host';，逐条核对是否每张基表（包括跨库表）都有GRANT SELECT ON db.table记录 - 必须逐表授权：
GRANT SELECT ON mydb.t1 TO 'definer_user'@'host';，不能只授mydb.*
SQL Server 报 “SELECT permission was denied on the object”：权限不继承，必须单独授视图本身
这个错误里的 “object” 就是视图名，和底层表权限完全无关。哪怕你对所有基表都有 SELECT，也得单独给视图授 SELECT 权限。
- 直接执行：
GRANT SELECT ON dbo.v_report TO app_user; - 如果视图引用了其他库的对象（如
OtherDB.dbo.Customers），目标库OtherDB中该用户也必须有SELECT权限 - 若视图里调用了函数（如
dbo.fn_format_date()），还需补：GRANT EXECUTE ON dbo.fn_format_date TO app_user;
Oracle 报 ORA-01031 创建失败：角色权限在编译时不可用，必须显式授对象权限
只执行 GRANT CREATE VIEW TO scott 不够——创建视图时 Oracle 会立即校验所有被引用对象的可读性，而角色带来的 SELECT 权限在编译上下文中默认不生效。
- 假设视图引用
hr.employees，必须执行：GRANT SELECT ON hr.employees TO scott; - 跨多个 schema 时，每张被引用的表/视图都要单独授权，不能靠
SELECT ANY TABLE - 检查当前会话真实权限：
SELECT * FROM SESSION_PRIVS;（不是SESSION_ROLES） - 如果是 JDBC/cx_Oracle 连接，注意连接字符串是否带
currentSchema=xxx，它会改变权限查找上下文
重建视图时最容易忽略的细节：CURRENT_USER ≠ USER()，且 FLUSH PRIVILEGES 不一定管用
用 CREATE OR REPLACE DEFINER = CURRENT_USER 是安全做法，但 CURRENT_USER() 返回的是认证账号（比如 'app'@'10.%'），而 USER() 是你声明的登录身份（比如 'app'@'localhost'），两者常不一致。
- 重建前务必确认你有
CREATE VIEW和DROP VIEW权限，且目标库下无同名表干扰 - MySQL 8.0+ 启用角色后，即使用户被赋予了角色，新连接中角色默认未激活，需显式
SET ROLE role_name;或配置activate_all_roles_on_login=ON -
FLUSH PRIVILEGES只对直接修改mysql.user表有效；通过GRANT授权后一般不用刷，但某些旧版本或特殊部署可能需要
