MySQL视图权限需单独授予，因视图不存数据且执行依赖DEFINER或INVOKER身份；默认SQL SECURITY DEFINER模式下，调用者只需视图权限，但DEFINER账户必须存在并具备底层表权限，且应避免使用高危账号。
视图本身不存储数据，但权限控制必须单独授予
MySQL 视图只是保存的 SELECT 语句，查询时实时执行底层表逻辑。这意味着：即使你给用户授予了视图的 SELECT 权限，该用户也**不会自动获得视图所依赖的基础表权限**——MySQL 5.7.6+ 默认启用 sql_mode=NO_SQL_MODE 下的严格检查，会直接报错 ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist 或更常见的 ERROR 1142 (42000): SELECT command denied to user。
- 视图的执行实际以
DEFINER身份（创建者）或INVOKER身份（调用者）进行，取决于创建时是否显式指定SQL SECURITY - 默认是
SQL SECURITY DEFINER，即按定义者权限运行，此时调用者只需有视图本身的权限，无需底层表权限 - 若设为
SQL SECURITY INVOKER，则调用者必须同时拥有视图 + 所有被引用表的对应权限 - 生产环境建议统一用
DEFINER模式，并确保DEFINER账户存在且稳定（避免用临时账号或已删用户）
创建视图时必须显式指定 DEFINER，否则可能继承当前登录用户
如果创建视图时不写 DEFINER，MySQL 会把当前连接用户设为 DEFINER。一旦该用户被删或密码过期，所有依赖它的视图都会失效。
CREATE DEFINER='reporter'@'localhost' SQL SECURITY DEFINER VIEW v_user_summary AS SELECT id, username, COUNT(*) AS login_count FROM users u JOIN login_logs l ON u.id = l.user_id GROUP BY u.id, u.username;
-
DEFINER必须是已存在的、具备底层表SELECT权限的账户 - 不要用
'root'@'%'这类高危账户作为DEFINER，应新建专用账号（如'view_definer'@'localhost'）并最小化授权 - 执行
SHOW CREATE VIEW v_user_summary可确认当前DEFINER和SQL SECURITY设置
给业务用户授予权限时，只授视图权限，不碰基表
权限隔离的核心就在这里：让前端应用或报表用户只能看到脱敏/聚合后的结果，完全接触不到原始表结构和敏感字段。
GRANT SELECT ON mydb.v_user_summary TO 'app_user'@'10.20.30.%';
- 禁止执行
GRANT SELECT ON mydb.users TO ...—— 否则视图形同虚设 - 如果视图里用了函数（如
MD5()、DATE_SUB()），确保用户也有对应函数执行权限（通常系统函数默认允许，但自定义函数需额外EXECUTE） - 注意反向推断风险：即使视图隐藏了密码字段，但如果暴露了
password_hash LIKE 'a%' OR password_hash LIKE 'b%'类条件，仍可能被枚举——权限控制不能替代逻辑层脱敏
修改基表结构后，视图可能失效且不报错，需手动检查
MySQL 不会在基表 ALTER 后自动刷新视图元数据。如果删了视图中引用的列，或改了列名，后续查视图时才会报错：ERROR 1356 (HY000): View 'mydb.v_user_summary' references invalid table(s) or column(s)。
- 上线前对涉及视图的 DDL 变更，务必执行
SELECT * FROM v_user_summary LIMIT 1验证 - 可用
SELECT TABLE_NAME, VIEW_DEFINITION FROM information_schema.VIEWS WHERE TABLE_SCHEMA='mydb'定期扫描依赖关系 - 复杂视图建议加注释说明依赖哪些表和字段，写在
CREATE VIEW的注释里，方便协作维护
视图 + 权限配合的关键不在语法多炫，而在定义者身份是否可控、调用者权限是否收口、基表变更是否可感知——这三处漏掉任何一环，权限模型就等于没建。
