直接GRANT SELECT ON view_name不安全，因视图无访问隔离能力：用户可绕过视图直查基表、通过SHOW CREATE VIEW反推敏感结构，或利用元数据（如information_schema）重建表结构；真正生效需三步：先REVOKE基表SELECT权、再GRANT视图SELECT权、最后DENY SHOW DATABASES及限制information_schema访问。
不能只给视图授 SELECT 权限就完事——开发人员仍可能绕过视图直接查基表，或通过元数据暴露敏感字段。真正生效的前提是：先清空基表权限、再单授视图、且必须禁用元数据访问。
为什么直接 GRANT SELECT ON view_name 不安全
MySQL 视图本身不构成访问隔离层。常见错误现象包括：
- 用户执行
SHOW CREATE VIEW view_user_summary看到定义语句，从而反推出基表名和字段名 - 若用户仍有
SELECT ON database_name.*，就能直接SELECT * FROM users绕过视图 - 旧账号曾被授予
ALL PRIVILEGES或角色继承了EXECUTE，GRANT SELECT ON view完全无效
必须显式回收基表权限并单独授权视图
操作顺序不能颠倒，否则权限叠加导致失效：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先执行
REVOKE SELECT ON database_name.* FROM 'dev'@'%'（注意不是REVOKE ALL，而是明确撤掉基表读权） - 再执行
GRANT SELECT ON database_name.view_user_summary TO 'dev'@'%' - 如果视图跨库（如引用
log_db.audit_log），需额外对那个库也执行REVOKE SELECT，否则仍可直查 - 确认视图创建时用了
SQL SECURITY DEFINER（默认值），避免被覆盖成INVOKER——后者会让查询按调用者权限执行，彻底失效
必须禁用 information_schema 和 SHOW DATABASES
否则用户能通过元数据重建整个表结构：
-
REVOKE SHOW DATABASES ON *.* FROM 'dev'@'%'→ 否则SHOW DATABASES会列出所有库名 -
GRANT SELECT ON information_schema.TABLES TO 'dev'@'%'可选，但仅限需要SHOW CREATE TABLE的场景；不要授information_schema.*，范围太大 -
GRANT SELECT ON information_schema.COLUMNS TO 'dev'@'%'同理，仅当 ORM 或 BI 工具依赖字段注释时才加 - 验证时务必用新连接测试：
SELECT * FROM information_schema.COLUMNS LIMIT 1应报ERROR 1142 (42000)
视图定义里不能含敏感字段或越权条件
权限配置再严，视图本身写错也会泄露数据：
- 查
SELECT VIEW_DEFINITION FROM information_schema.VIEWS WHERE TABLE_NAME = 'view_user_summary'，确认没包含password_hash、phone、id_card等原始列 - WHERE 条件不能依赖用户不可见的字段（如
WHERE tenant_id = @current_tenant），否则视图结果不可控 - 避免在视图中
JOIN未授权库的表，否则创建会失败，或成功后因权限缺失导致运行时报错 - 主从环境要同步检查从库权限，视图在从库上也要有对应授权，否则复制线程可能中断
最易被忽略的是：权限变更后旧连接不刷新，SHOW GRANTS 看起来干净，但实际行为仍按旧快照执行。必须用新连接验证三件事：SHOW DATABASES、SELECT * FROM view_name、SELECT * FROM base_table —— 前者应只显示一个库，中间成功，后者必须报错。
