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 的注释里，方便协作维护

视图 + 权限配合的关键不在语法多炫，而在定义者身份是否可控、调用者权限是否收口、基表变更是否可感知——这三处漏掉任何一环，权限模型就等于没建。