视图本身不存储数据，但权限控制必须单独授予
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的注释里，方便协作维护
视图 + 权限配合的关键不在语法多炫，而在定义者身份是否可控、调用者权限是否收口、基表变更是否可感知——这三处漏掉任何一环，权限模型就等于没建。
