MySQL无法直接仅授权视图访问，需先回收用户对基表的SELECT权限，再单独授予视图SELECT权限，并确保视图使用SQL SECURITY INVOKER、用户拥有库级USAGE权限且无角色继承的基表权限。
如何给 MySQL 用户只开视图访问权限
MySQL 本身不支持「仅授权视图、禁止基表」的原子操作——GRANT SELECT ON view_name 会自动带上其依赖的基表权限（如果用户没有，会报错），所以必须靠权限剥离：先禁掉所有基表权限，再单独开视图权限。
常见错误现象：ERROR 1142 (42000): SELECT command denied to user，明明 GRANT SELECT ON mydb.myview 成功了，但查询仍失败。原因往往是用户还残留着对基表的 USAGE 或旧 SELECT 权限，而 MySQL 在检查时优先走基表权限路径，绕过了视图授权。
- 先用
SHOW GRANTS FOR 'user'@'host'看当前所有权限，重点找带ON `mydb`.*或具体基表名的SELECT - 用
REVOKE SELECT ON mydb.table1 FROM 'user'@'host'逐个回收基表权限（不能用REVOKE ALL，它不清理视图相关权限） - 确认基表权限清空后，再执行
GRANT SELECT ON mydb.myview TO 'user'@'host' - 最后
FLUSH PRIVILEGES（仅当直接改了 mysql.db 表才必须；常规 GRANT 后可省）
视图定义里用了 DEFINER 会怎样
如果视图是用 DEFINER = 'admin'@'%' 创建的，那用户查视图时，MySQL 会以 admin 身份去校验基表权限——此时你删掉普通用户的基表权限也没用，只要 admin 有权限，查询就通。这等于绕过了你的权限隔离意图。
使用场景：DBA 维护统一视图时常用 DEFINER，但交付给业务用户前必须改掉。
- 查视图定义：
SHOW CREATE VIEW mydb.myview，看第一行有没有DEFINER - 安全做法是重建视图，显式指定
SQL SECURITY INVOKER：CREATE ALGORITHM=MERGE SQL SECURITY INVOKER VIEW mydb.myview AS SELECT ...
- 如果无法重建（比如视图跨库或含函数），只能确保
DEFINER账户本身也被严格限制——但它一旦被提权，整个视图链就失效
为什么有时候 GRANT SELECT ON VIEW 还是报错
除了 DEFINER 和残留权限，还有三个硬性前提没满足就会失败：
- 用户必须对视图所在的数据库有
USAGE权限（哪怕只是空壳）：GRANT USAGE ON mydb.* TO 'user'@'host' - 视图引用的所有基表，其所属数据库必须对用户可见（即用户至少有该库的
USAGE）；如果视图跨库SELECT FROM db1.t1 JOIN db2.t2，那用户得同时有db1.*和db2.*的USAGE - MySQL 8.0+ 引入了角色机制，如果用户通过角色继承权限，要确认角色本身没带基表
SELECT——SHOW ROLE GRANTS FOR 'user'@'host'可查
权限剥离后性能和兼容性要注意什么
权限剥离本身不损耗查询性能，但可能暴露隐藏问题：比如视图里用了 UNION 或子查询，而用户原本靠基表权限能走索引，现在因权限路径变化导致执行计划退化。
兼容性上，MySQL 5.7 和 8.0 对 SQL SECURITY INVOKER 的处理一致，但 8.0 默认创建视图用 DEFINER，5.7 则默认 INVOKER（取决于 sql_mode）。升级后务必复查。
- 测试时别只跑
SELECT *，加EXPLAIN FORMAT=TREE看实际执行是否还走原索引 - 如果视图含
GROUP BY或窗口函数，确认用户权限足够访问涉及的系统表（如performance_schema），否则可能报Access denied for table - 应用连接池复用账户时，注意权限变更后需重启连接，否则缓存的权限状态可能不刷新
事情说清了就结束。真正难的不是 GRANT 那一行命令，而是把所有隐式依赖路径都摸清楚——尤其是 DEFINER、跨库引用、角色继承这三处，漏掉任何一个，权限就形同虚设。
