直接授视图权限更安全可控，但需确保基表schema的USAGE权限到位且DEFINER账户有效；视图创建须避SELECT*、显式过滤敏感字段、加WITH CHECK OPTION；推荐角色+前缀命名统一授权。
直接给用户授视图权限，比逐个授权基表更安全、更可控——但前提是视图定义得当、权限配置不遗漏。
为什么不能只 GRANT SELECT ON view 而不碰基表
视图本身不存数据，执行时仍要访问底层表。不同数据库对「谁的权限生效」处理不同：
- PostgreSQL 和 SQL Server 默认用
DEFINER权限模型：检查视图创建者的权限，不是调用者 - MySQL 8.0+ 默认是
INVOKER，但多数生产环境显式设为DEFINER统一管控 - 哪怕你
GRANT SELECT ON v_active_users TO analyst，如果该视图查了users和orders两张表，而analyst对其中任一表没有USAGEon schema（尤其非publicschema），照样报错permission denied for table orders
所以，授权视图 ≠ 放心交差；必须同步确认基表所在 schema 的 USAGE 权限是否到位。
CREATE VIEW 时必须避开的三个坑
视图写法直接影响权限隔离效果和后续稳定性：
- 别用
SELECT *：字段增减会导致下游应用解析失败，比如SELECT * FROM v_user_summary突然多出一列last_login_ip，Java 应用可能抛SQLFeatureNotSupportedException - 敏感字段必须显式列出，而不是靠
GRANT SELECT (id,name) ON users：MySQL 5.7 不支持列级授权；PostgreSQL 列授权对UPDATE无效；且加新列后必须补授权，运维不可持续 - 需要行级过滤时，务必加
WITH CHECK OPTION：例如CREATE VIEW v_finance_daily AS SELECT * FROM transactions WHERE type = 'revenue' WITH CHECK OPTION，否则用户可能通过INSERT INTO v_finance_daily插入type='expense'记录
角色 + 视图前缀才是可扩展的权限分发方式
当有「BI 工程师」「运营专员」「风控分析师」多个角色，各自需要不同维度的用户数据时，手动 GRANT SELECT ON v_user_basic TO analyst 会迅速失控：
- 建统一基础角色
role_readonly，只赋予对所有v_*视图的SELECT - 再让各业务角色继承它：
GRANT role_readonly TO analyst - 视图命名带域前缀，如
v_finance_revenue_daily、v_marketing_campaigns，方便后期用正则批量审计或授权（例如SELECT table_name FROM information_schema.views WHERE table_name LIKE 'v_finance%'）
这样，新增一个 v_finance_pnl_monthly 视图，只需确保它在 role_readonly 授权范围内，所有下游角色自动获得访问权，无需改用户权限。
MySQL 8.0+ 角色管理让视图权限真正解耦
MySQL 原生角色支持让视图权限分配不再依赖 DBA 手动操作每个用户：
- 创建角色：
CREATE ROLE 'report_reader', 'etl_writer'; - 把视图权限打包进角色：
GRANT SELECT ON sales_db.v_daily_summary TO 'report_reader'; - 分配角色：
GRANT 'report_reader' TO 'alice'@'%'; - 设为默认角色（避免每次会话手动
SET ROLE）：ALTER USER 'alice'@'%' DEFAULT ROLE 'report_reader';
关键点在于：角色本身不绑定具体用户，权限变更只需改角色定义，所有持有该角色的用户即时生效——这是直接 GRANT 用户做不到的弹性。
最常被忽略的是 schema 级 USAGE 权限和 DEFINER 账户的生命周期管理。一个 DEFINER='dba_old'@'localhost' 的视图，只要 dba_old 账号被删或密码过期，整个视图立刻不可用，错误信息却只显示表权限拒绝，排查方向极易跑偏。
