MySQL视图不自动继承基表权限，需单独授权或使用SQL SECURITY DEFINER；WITH CHECK OPTION防止违反视图条件的DML操作；视图权限独立于表，且无法实现动态行级过滤。
视图本身不自动继承底层表权限
创建视图后，用户即使对视图有 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 中的动态行权限——那是代理层、中间件或应用逻辑的事。
