能行，但需用 sql security definer 创建视图，definer 账号须有源表 select 权限，用户仅需视图 select 权限；mysql 8.0.16+ 支持视图单独授权，5.7 需注意语法和 sql_mode。
只给用户查视图的权限，不给底层表权限，能行吗？
能行，但得绕开 MySQL 的权限检查机制漏洞——CREATE VIEW 和 SELECT 权限默认不校验视图定义里的源表权限。如果只授 SELECT 给视图，而没关 SQL SECURITY，用户可能通过视图间接读到不该看的表。
- 必须显式用
SQL SECURITY DEFINER创建视图（否则默认是INVOKER，会校验调用者对源表的权限，反而失效） - 创建视图的账号必须拥有源表的
SELECT权限（DEFINER账号需要，不是最终用户） - 目标用户只需
SELECT视图本身，不需任何底层表权限 - 注意：MySQL 8.0.16+ 才支持对视图单独授权；5.7 及以前必须先
GRANT SELECT ON database.view_name，且确保sql_mode不含NO_AUTO_CREATE_USER
GRANT SELECT ON view_name 失败：常见报错和解法
最常卡在 ERROR 1142 (42000): SELECT command denied to user，不是权限没给，而是视图还没“被 MySQL 认可”。
- 先确认视图存在且语法合法：
SHOW CREATE VIEW view_name，若报错说明视图损坏或依赖表已删 - 检查视图定义里是否用了函数、临时表或用户变量——这些会导致视图无法被授权（MySQL 认为不可控）
- 如果视图基于另一个视图，要逐级确认所有上游视图都已显式授权，MySQL 不自动递归授权
- 执行
FLUSH PRIVILEGES一般没用；权限缓存更新靠的是GRANT语句本身触发，不是手动刷
视图权限和 SELECT * FROM table 的性能/安全差异
视图不是数据副本，只是保存的查询语句，所以权限隔离是逻辑层的，不影响查询性能本身，但会影响优化器行为。
- MySQL 8.0+ 支持视图合并（view merging），如果视图没加
ALGORITHM = TEMPTABLE，查询可能被重写成直接查底表——此时若用户没底表权限，就会报错 - 想强制走视图封装逻辑，建视图时加
ALGORITHM = TEMPTABLE或ALGORITHM = MERGE并配合SQL SECURITY DEFINER - 敏感字段别依赖视图“隐藏”——如果用户有
SHOW CREATE VIEW权限，就能看到视图定义，知道底层查了哪些列 - 视图不防 SQL 注入，也不加密数据；它只是访问控制的第一道筛子，不是安全边界
MySQL 5.7 升级到 8.0 后视图权限突然失效？
大概率是 sql_mode 变了，或者权限表结构升级没跑完。
- 检查
mysql.role_edges和mysql.proxies_priv表是否存在——8.0 权限系统重构，老版本 GRANT 可能没同步到新表 - 运行
mysql_upgrade（不是可选，是必须），否则information_schema.VIEWS可能不返回视图元数据，导致授权失败 - 8.0 默认启用
require_row_format类似限制，如果视图用了不支持的函数（如UUID()），会被拒绝执行，报ERROR 1356 - 用户账号的
authentication_string字段长度在 8.0 变更过，如果用老备份恢复，可能因哈希格式不兼容导致权限加载异常
事情说清了就结束。真正麻烦的不是授权动作本身，而是 DEFINER 账号的生命周期管理——那个账号密码过期、被删、或权限被回收，整个视图就垮了。
