直接授予视图SELECT权限不够，因MySQL 5.7默认SQL SECURITY DEFINER要求DEFINER有底层对象权限，且当前用户仍需满足依赖对象访问检查；必须显式声明DEFINER、确保其拥有全部引用对象权限，并避免使用*或不安全条件。
为什么直接给视图授 SELECT 权限还不够
MySQL 5.7 中，GRANT SELECT ON db.view_name 确实能控制用户是否能查该视图，但容易忽略两个关键前提：视图本身必须存在且可执行；视图定义里引用的底层表（或函数、其他视图）的权限也必须满足。如果 view_user_summary 是基于 users 表加 WHERE status = 'active' 构建的，而用户对 users 表没有 SELECT 权限，即使视图上授了权，查询时仍会报 ERROR 1142 (42000): SELECT command denied。
这是因为 MySQL 5.7 默认使用 SQL SECURITY DEFINER（除非显式声明为 INVOKER），但前提是 DEFINER 用户（通常是创建者）必须有底层对象权限——而普通用户不是 DEFINER，所以权限检查仍会落到当前用户身上（即“invoker context”行为在部分场景下实际生效）。更稳妥的做法是显式指定安全上下文并验证依赖。
- 务必在
CREATE VIEW时写明SQL SECURITY DEFINER，不依赖默认值 - DEFINER 账户（如
'admin'@'localhost'）必须对视图中所有引用对象（表、函数、其他视图）拥有对应权限 - 用户只需对视图本身有
SELECT权限，无需对底层表授权 - 若视图中用了
NOW()、USER()等函数，DEFINER 还需有EXECUTE权限（MySQL 5.7 默认开启，但某些加固配置可能关闭）
如何创建一个真正隔离的只读视图入口
目标是让开发人员只能看到 id、username、created_at 三字段，且仅限 status = 'active' 的行。不能靠事后回收权限补救，得从视图定义和授权链一起卡死。
正确写法示例：
CREATE ALGORITHM = MERGE SQL SECURITY DEFINER VIEW app_db.v_active_users AS SELECT id, username, created_at FROM app_db.users WHERE status = 'active';
关键点：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
-
ALGORITHM = MERGE：确保条件能下推到基表，避免临时表导致全量扫描；UNDEFINED可能在优化器判断后退化为TEMPTABLE，丧失 WHERE 下推能力 - 库名
app_db必须显式写出，不能省略；否则在跨库查询或复制环境中行为不可控 - 视图名用小写字母+下划线，避免关键字冲突；若库名含短横线（如
my-app），必须用反引号包裹：`my-app`.v_active_users
授权后仍查不到？排查这三点
用户执行 SELECT * FROM v_active_users 报错，大概率不是语法问题，而是权限未真正落地或匹配失效。
- 确认用户连接时的 host 是否与 GRANT 语句中完全一致：比如授权的是
'dev'@'192.168.1.%'，但应用连的是'dev'@'192.168.1.105'，虽然网段匹配，但 MySQL 会优先匹配最精确的 host 记录；查SELECT user, host FROM mysql.user WHERE user = 'dev'; - 执行
SHOW GRANTS FOR 'dev'@'%';，输出里必须出现GRANT SELECT ON `app_db`.`v_active_users`—— 注意反引号和库表名拼写 - MySQL 5.7 不支持
REVOKE SELECT ON INFORMATION_SCHEMA.*，所以用户仍能查INFORMATION_SCHEMA.VIEWS看到视图定义；但这不影响数据访问控制，只是元数据可见性无法靠权限关掉（需代理层过滤或禁用show databases）
别让视图变成权限绕过通道
视图看似安全，但若设计不当，反而暴露更多数据。例如，有人写：
CREATE VIEW app_db.v_debug AS SELECT *, NOW() as ts FROM app_db.users;
这就等于把整张表都放出去了，还附带时间戳——哪怕只授视图权限，也等同于开放全表。
- 永远不要在视图里用
*，显式列出每一列 - 避免在 WHERE 条件中引用用户可控参数（如
WHERE tenant_id = @current_tenant），MySQL 5.7 不支持视图参数化，这类写法实际无效或引发意外行为 - 如果业务需要多租户隔离，不要依赖视图 WHERE，而应在应用层拼接
tenant_id = ?条件，视图只做字段裁剪 - 定期用
SELECT table_schema, table_name, view_definition FROM information_schema.views WHERE table_schema = 'app_db';审计视图内容，防止被悄悄修改
最常被忽略的一点：视图权限不继承库级权限，但会受全局权限覆盖。如果用户之前被授予过 SELECT ON *.*，后来再单独给视图授权，旧权限依然有效——必须先 REVOKE SELECT ON *.* FROM 'dev'@'%'，再 GRANT SELECT ON app_db.v_active_users。
