必须显式创建SQL SECURITY DEFINER视图并确保DEFINER账号拥有基表SELECT权限，同时撤掉用户基表权限、授予视图权限、禁用SHOW DATABASES，否则视图隔离失效。
能行，但必须先撤掉基表权限、显式创建 SQL SECURITY DEFINER 视图，并确保用户没有 SHOW DATABASES 或 information_schema 访问权——否则“只看视图”只是假象。
为什么直接 GRANT SELECT ON view_name 不够？
MySQL 默认用 SQL SECURITY INVOKER（调用者权限）执行视图。如果用户没被收回基表权限，SELECT 会直接查底层表；如果收回了，又因权限校验失败而报 ERROR 1142。根本矛盾在于：视图本身不自带访问控制能力，它只是查询封装。
- 用户有基表
SELECT权限 → 可绕过视图直查表 - 用户没基表
SELECT权限，且视图是INVOKER→ 执行SELECT * FROM myview直接失败 - 唯一解法：视图必须是
DEFINER，且DEFINER账号拥有源表权限
必须做的三步清理动作
光建视图、授视图权限，90% 的案例都会漏掉其中一环，导致隔离失效。
-
REVOKE SELECT ON database_name.* FROM 'dev'@'%'—— 先清空库级基表权限，包括所有表和视图（注意：这不会影响已存在的视图定义） -
GRANT SELECT ON database_name.my_view TO 'dev'@'%'—— 只放行指定视图，别漏写数据库名 -
REVOKE SHOW DATABASES ON *.* FROM 'dev'@'%'—— 否则SHOW DATABASES仍暴露其他库名，用户可尝试跨库探测
创建视图时最容易踩的坑
很多视图看似建成功了，但授权时卡在 ERROR 1142，问题不在 GRANT 语句，而在视图本身不被 MySQL “信任”。
- 必须显式声明：
CREATE DEFINER='admin'@'localhost' SQL SECURITY DEFINER VIEW my_view AS ...，不能依赖默认值 - 避免在视图定义中使用
USER()、@var、子查询里带临时表——MySQL 8.0+ 会拒绝给这类视图授予权限 - 如果视图基于另一个视图（嵌套），上游视图也必须是
DEFINER模式，且已单独授过SELECT - 检查依赖：
SHOW CREATE VIEW my_view，若报错说明视图损坏或引用了已删表
验证是否真隔离成功
别只看 SHOW GRANTS 输出里有没有 SELECT，要连上去跑真实命令：
-
SHOW DATABASES;→ 应只显示你授权的那个库，其他库名不可见 -
SELECT * FROM information_schema.TABLES LIMIT 1;→ 必须报ERROR 1142 -
SELECT * FROM database_name.my_view;→ 成功返回数据 -
SELECT * FROM database_name.base_table;→ 明确报ERROR 1142
只要其中任意一条不满足，就说明权限链某处断了——常见是漏了 USAGE 或 REVOKE SHOW DATABASES。
