视图本身不自动继承底层表权限
创建视图后，用户即使对视图有
SELECT权限，也不代表能查到底层表——MySQL 会检查调用者对基表的权限，除非显式启用 SQL SECURITY DEFINER。常见错误是：管理员只给用户授了视图的
SELECT，但忘了授权基表，结果执行
SELECT * FROM my_view时直接报错
ERROR 1142 (42000): SELECT command denied to user。
解决办法是两种路径之一：
给用户同时授予视图和所有基表的SELECT（简单但粒度粗） 用
DEFINER方式创建视图，让查询以定义者身份执行权限检查（推荐）
例如：
CREATE ALGORITHM=MERGE VIEW sales_summary AS SELECT user_id, SUM(amount) total FROM orders WHERE status = 'done' GROUP BY user_id WITH CHECK OPTION;必须加上
SQL SECURITY DEFINER才能绕过调用者对
orders表的权限限制：
CREATE SQL SECURITY DEFINER VIEW sales_summary AS ...
WITH CHECK OPTION 是行级过滤的关键开关
当视图包含
WHERE条件（比如只暴露状态为
'active'的用户），
WITH CHECK OPTION能阻止用户通过视图插入或更新违反该条件的数据。没有它，
INSERT INTO user_active_view VALUES (...)可能成功写入
status='inactive'的记录，彻底绕过视图逻辑。
注意点：
CASCADED（默认）：检查视图及其依赖的所有视图的条件
LOCAL：只检查当前视图的
WHERE条件，忽略嵌套视图约束 仅对
INSERT/
UPDATE生效，
DELETE不受其限制
GRANT 对视图的操作和对表的操作必须分开执行
MySQL 不会把
GRANT SELECT ON db.* TO 'u'@'%'自动延伸到视图上。视图在权限系统里是独立对象，哪怕它和表同名、同库，也得单独授权：
GRANT SELECT ON mydb.sales_summary TO 'reporter'@'%';
否则即使用户能连上库、能看到
SHOW FULL TABLES IN mydb列出该视图，执行
SELECT仍会报
ERROR 1142。同样，如果想让用户能修改视图数据（前提是视图可更新），还得额外给
INSERT/
UPDATE/
DELETE权限，且必须确保视图满足可更新条件（如无聚合、无
DISTINCT、单表等）。
视图权限无法替代行/列级动态过滤
视图只能做静态过滤：建的时候写死
WHERE dept_id = 10，就只能服务部门 10。如果要实现“每个用户查自己部门”，不能靠一个视图搞定，因为视图不支持参数化。这时候容易误以为加个
USER()就行：
CREATE VIEW my_dept AS SELECT * FROM employees WHERE dept_id = SUBSTRING_INDEX(USER(), '@', 1);
但这是错的——
USER()在视图创建时求值，不是每次查询时求值。真正可行的方式只有两种： 应用层拼接真实部门 ID，查具体视图（如
dept_10_view） 用存储过程封装动态 SQL，配合
PREPARE+
EXECUTE（但无法用在普通
SELECT场景）
所以别指望视图解决多租户或 RBAC 中的动态行权限——那是代理层、中间件或应用逻辑的事。
