从调用者权限和定义者权限的检查位置比较两种视图安全上下文

只读视图突然出现“调用者没有权限”，不一定说明视图本身坏了。MySQL 需要分两层判断：调用者先要有访问视图的权限；视图继续访问基表或其他对象时，还要按照视图的安全上下文检查底层权限。SQL SECURITY DEFINER 默认使用定义者账户检查底层对象，SQL SECURITY INVOKER 则使用当前调用者检查。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/create-view.html

本文复盘一个常见故障：同一个视图对管理员可用，对报表账号却失败。重点不是给账号堆更多授权，而是先找出权限检查发生在哪一层，再决定是否需要调整视图的安全上下文。

影响面：为什么只有部分调用者失败

故障通常表现为“视图存在、SQL 也很简单，但不同账号得到不同结果”。这是因为调用视图至少经过两个检查点：

1. 调用者是否有权访问这个视图，例如执行 SELECT * FROM report_order; 所需的视图权限。
2. 视图定义访问的基表、列或存储函数，由谁的权限来完成检查。

第一层决定调用者能不能进入视图；第二层决定视图内部的对象能不能继续被读取。只给调用者补充基表权限，未必是正确修复；如果视图本来就应该封装基表，反而可能扩大直接访问范围。

时间线：从创建视图到引用视图

把故障按时间拆开，通常能快速排除“创建成功就代表所有人都能查询”的误解。

1. 创建时：定义者先要能定义这条查询

创建视图时，创建者需要具备创建视图所需的权限，同时要能使用定义中引用的对象。省略 DEFINER 时，默认定义者就是执行 CREATE VIEW 的账户。

-- 创建时先明确这是一个只读报表视图
CREATE VIEW report_order AS
SELECT order_id, customer_id, total_amount
FROM sales_order;

这个阶段成功，只能说明定义当时通过了创建检查；不能替代之后每次引用视图时的权限判断。

2. 引用时：调用者先过视图这一层

报表账号执行查询时，MySQL 先判断它是否有访问 report_order 的权限。如果这一层失败，后面的安全上下文还没有机会发挥作用。

-- 这条查询的第一个关注点是调用者能否访问视图
SELECT order_id, total_amount
FROM report_order;

3. 继续展开时：才判断基表权限来源

视图被引用后，MySQL 根据 SQL SECURITY 决定用定义者账户还是调用者账户检查视图访问的基表、列和相关对象。若视图调用存储函数，函数自身的安全属性还会影响函数内部语句的权限判断。

触发条件：两种 SQL SECURITY 的检查对象

可以把同一份视图定义写成两个版本，用来理解“检查位置”而不是死记关键字。

-- DEFINER：底层对象按定义者账户检查，适合封装固定只读查询
CREATE ALGORITHM = UNDEFINED
SQL SECURITY DEFINER
VIEW report_order_definer AS
SELECT order_id, customer_id, total_amount
FROM sales_order;

-- INVOKER：底层对象按当前调用者检查，适合让调用者权限继续生效
CREATE ALGORITHM = UNDEFINED
SQL SECURITY INVOKER
VIEW report_order_invoker AS
SELECT order_id, customer_id, total_amount
FROM sales_order;

两者的核心差异可以压缩成下面这张表：

因此，INVOKER 并不是“所有人都能按自己的权限查询”，而是“底层对象检查使用调用者身份”；调用者仍然必须先被允许访问这个视图。

根因：默认值与 CURRENT_USER 的误判

这类故障最容易被两个细节放大。

默认就是 DEFINER

如果创建语句没有写 SQL SECURITY，MySQL 使用 DEFINER。所以看到一条历史视图没有写安全上下文时，不能把它理解成“跟随调用者”，而应该按定义者上下文分析。

CURRENT_USER() 不是普通登录用户名

在视图定义中，CURRENT_USER() 默认返回视图的定义者；对于 SQL SECURITY INVOKER 的视图，它返回当前调用者。这会影响审计字段、条件表达式和由视图调用的存储逻辑。排查时，先确认视图定义与安全属性，再解释身份函数的结果。

-- 查看视图保存的定义、定义者和安全上下文
SHOW CREATE VIEW report_order;

-- 只把身份结果用于定位，不把它当成额外授权操作
SELECT CURRENT_USER();

修复动作：先确认边界再选择上下文

修复顺序建议固定为四步，避免一遇到报错就给报表账号追加基表权限。

1. 确认第一层：让受影响账号只检查是否拥有访问目标视图所需的权限。
2. 确认第二层：用 SHOW CREATE VIEW 读取真实的 DEFINER 与 SQL SECURITY，不要凭视图名称猜测。
3. 对照目标：如果视图的目的就是封装固定的只读数据范围，优先评估 DEFINER；如果必须继承每个调用者的底层权限，评估 INVOKER。
4. 最小改动：只修改明确需要调整的视图定义，保留原查询列和过滤条件，并把变更原因写进发布记录。

-- 只有在确认目标是调用者权限模型后，才显式声明 INVOKER
CREATE OR REPLACE
SQL SECURITY INVOKER
VIEW report_order AS
SELECT order_id, customer_id, total_amount
FROM sales_order;

若目标是让视图继续承担稳定的数据封装职责，则应显式写出 SQL SECURITY DEFINER，并把定义者账户的生命周期纳入变更管理。无论选择哪一种，调用者对视图本身的访问权限都要单独确认。

防复发：把安全上下文写成可审查约定

• 新建视图时显式写出 SQL SECURITY，不要让读者从默认值反推意图。
• 命名或注释中说明视图是“固定封装”还是“按调用者过滤”，但不要把注释当成权限控制。
• 变更审核同时查看视图定义、定义者和底层对象范围，避免只审查 SELECT 文本。
• 把受影响账号分成“只能访问视图”和“还可直接访问基表”两类，分别记录预期结果。
• 涉及存储函数时，继续检查函数自身的 SQL SECURITY，因为函数内部可能有另一层权限上下文。

一句话总结：调用者永远先面对“能不能访问视图”，而 SQL SECURITY 决定视图展开后“用谁的权限访问底层对象”。明确这条分界线，就能把“部分账号失败”的现象还原成可定位、可审查的权限检查链路。

相关问题

省略 SQL SECURITY 时是 INVOKER 吗？

不是。MySQL 的默认值是 DEFINER，需要按定义者权限检查视图访问的底层对象。

使用 DEFINER 后调用者还需要视图权限吗？

需要。定义者上下文只影响视图访问的底层对象，不能替代调用者对视图本身的访问权限。

怎样快速确认一条视图的安全上下文？

使用 SHOW CREATE VIEW view_name; 查看保存的定义、定义者和 SQL SECURITY，再结合受影响账号的访问范围定位。