MySQL 存储过程 DEFINER 账号失效时怎样恢复执行权限

MySQL 存储过程调用失败时，如果错误与 DEFINER、权限或不存在的账号有关，修复重点不是给调用方盲目追加权限，而是先确认过程保存的 DEFINER 身份和 SQL SECURITY 模式。SQL SECURITY DEFINER 会在过程执行时使用定义者账号的权限；定义者账号不存在、被错误替换或缺少过程内部表权限，都可能让调用失败。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/stored-objects-security.html

推荐顺序：先读取 INFORMATION_SCHEMA.ROUTINES 中的 DEFINER 和 SECURITY_TYPE，再判断原账号是否应该恢复。账号仍是业务身份时补齐同一组 user@host 并授予最小权限；账号已废弃时，使用专用低权限定义者重建对象，或者在业务允许时改用 SQL SECURITY INVOKER。

先确定调用目标与权限边界

一次 CALL 至少涉及三个权限边界：调用者能否执行这个过程、过程以谁的身份访问内部对象、内部表和函数是否满足执行所需权限。调用者拥有 EXECUTE 只代表可以引用过程，并不自动把过程内部的 SELECT、INSERT 或 UPDATE 权限补给定义者。

还要注意 DEFINER 不是一个单独的用户名字符串，而是由用户名和主机部分共同组成的 MySQL 账号。例如 'report_exec'@'localhost' 与 'report_exec'@'%' 是两个不同的身份。恢复时只补用户名、不补正确的 host，问题仍可能存在。

从 ROUTINES 读取 DEFINER 和 SECURITY_TYPE

先在目标数据库中查出过程保存的元数据。这个查询只观察定义，不会执行过程；如果当前账号没有读取相关元数据的权限，应交给数据库管理员执行并把结果纳入变更记录。

-- 读取指定存储过程的定义者和安全上下文
SELECT
    ROUTINE_SCHEMA,
    ROUTINE_NAME,
    DEFINER,
    SECURITY_TYPE
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_SCHEMA = 'app'
  AND ROUTINE_NAME = 'report_orders'
  AND ROUTINE_TYPE = 'PROCEDURE';

SECURITY_TYPE 通常反映 DEFINER 或 INVOKER。如果结果是 DEFINER，下一步要检查 DEFINER 中完整的账号标识；如果结果是 INVOKER，过程执行时主要看调用方的权限，重建定义者账号可能并不能解决真正的缺权问题。

确认过程正文和依赖对象时，可以使用 SHOW CREATE PROCEDURE。输出中的定义者、参数和过程体是后续重建的输入，不能只凭记忆重新写一份。

-- 保存过程定义，便于重建前逐项核对
SHOW CREATE PROCEDURE app.report_orders;

按账号状态选择恢复路径

恢复决策先回答一个业务问题：原来的定义者账号是否仍然代表合法的服务身份。不要为了让 CALL 暂时成功，就把过程改成高权限管理员账号。

路径一：补齐原 DEFINER 账号

如果故障只是账号在迁移或恢复中丢失，应恢复完全相同的 user@host，再按过程实际访问的对象授予最小权限。下面的示例使用占位账号名，不包含真实密码；生产环境应按组织的账号创建和密钥管理流程完成认证配置。

-- 只有在确认原服务身份仍然有效时才补回同名账号
CREATE USER IF NOT EXISTS 'report_exec'@'localhost';

-- 只授予过程确实需要的表权限，不直接授予全库权限
GRANT SELECT ON app.orders TO 'report_exec'@'localhost';
GRANT SELECT ON app.order_items TO 'report_exec'@'localhost';

-- 让调用者可以引用过程；调用者账号按实际业务单独授权
GRANT EXECUTE ON PROCEDURE app.report_orders TO 'app_reader'@'localhost';

如果原账号存在但缺少某张表的权限，补授权即可；如果账号的 host 部分不同，应该先核对过程中的 DEFINER，不要通过创建一个更宽泛的 host 账号来“碰运气”。

路径二：用专用定义者重建对象

当原账号已经退出系统，继续复活它会把旧的身份生命周期带回生产环境。这时应先保存 SHOW CREATE PROCEDURE 的结果，再由有权限的专用迁移账号创建一个只拥有必要表权限的新定义者。没有 SET_ANY_DEFINER 时，最稳妥的方式是让专用账号自己执行创建语句，并使用 CURRENT_USER，避免替他人伪造定义者。

-- 由专用迁移账号执行，CURRENT_USER 会绑定当前执行账号
DROP PROCEDURE IF EXISTS app.report_orders;

-- 过程体应来自 SHOW CREATE PROCEDURE 的核对结果
CREATE DEFINER = CURRENT_USER PROCEDURE app.report_orders()
SQL SECURITY DEFINER
BEGIN
    -- 示例只读取订单数据，实际过程体按已审核版本恢复
    SELECT order_id, created_at, total_amount
    FROM app.orders
    WHERE status = 'paid';
END;

重建前要确认参数列表、返回行为、字符集、依赖表和调用者的 EXECUTE 权限。DROP 与 CREATE 不是无损操作，必须在迁移窗口中执行，并把过程体作为代码审查对象，而不是临时拼接。

路径三：改用 INVOKER

如果过程本来就应当按照每个调用者的权限运行，可以把安全上下文改成 INVOKER。这不是绕过权限，而是把权限责任明确交给调用方：调用者除了需要 EXECUTE，还必须拥有过程内部语句实际需要的权限。

-- 仅当业务允许调用者直接承担内部对象权限时使用
ALTER PROCEDURE app.report_orders
    SQL SECURITY INVOKER;

改成 INVOKER 后，要重新检查所有调用方。原来依赖定义者权限读取表的调用者，可能立即出现缺少 SELECT 的错误；这正是权限边界变化带来的兼容性影响。

错误处理和权限收尾

修复后不要只用一个管理员账号调用一次就宣布完成。至少应分别确认：过程定义中的 DEFINER 是否已更新、SECURITY_TYPE 是否符合设计、调用者是否有 EXECUTE、定义者或调用者是否拥有过程内部对象权限。验证应使用与线上相同的调用账号，并把结果写入变更记录。

-- 复查过程元数据，确认迁移后的安全上下文
SELECT ROUTINE_NAME, DEFINER, SECURITY_TYPE
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_SCHEMA = 'app'
  AND ROUTINE_NAME = 'report_orders';

-- 用业务调用账号执行，避免管理员权限掩盖真实缺权
CALL app.report_orders();

如果执行仍失败，按错误类型区分：

• 提示找不到定义者或对象成为 orphan：检查 DEFINER 的 user 和 host 是否准确，或按路径二重建。
• 提示表、视图或函数权限不足：检查 SQL SECURITY 对应的实际执行账号，以及过程体引用的每个对象。
• 提示调用者不能执行过程：给业务账号授予该过程的 EXECUTE，不要把所有表权限直接授给调用者。
• 改用 INVOKER 后才失败：这是预期的权限模型变化，按调用方逐项补齐合法的对象权限。

MySQL 会阻止删除或重命名仍被存储对象作为 DEFINER 的账号，这也是避免产生孤立对象的重要保护。账号下线流程应先盘点 INFORMATION_SCHEMA.ROUTINES、视图、触发器和事件，再迁移定义者或按顺序清理依赖。

兼容性清单

结论：DEFINER 失效问题的修复单位是“账号身份 + 安全上下文 + 对象权限”三者的组合。原身份仍合法就恢复原账号；身份已废弃就用最小权限的专用定义者重建；如果业务要求调用方自负权限，再选择 INVOKER。这样既能恢复执行，也不会把一次权限故障变成长期的过度授权。

相关问题

问：调用者已经有 EXECUTE，为什么仍然提示权限不足？
答：EXECUTE 只允许调用过程；在 SQL SECURITY DEFINER 下，还要检查定义者访问过程内部对象的权限。

问：DEFINER 里的 host 可以直接改成 % 吗？
答：不建议。host 是账号身份的一部分，放宽范围会改变认证和权限边界，应先确认原账号设计，再选择精确的 user@host。

问：什么时候应该使用 SQL SECURITY INVOKER？
答：当过程不应替调用者获得额外数据访问能力，且每个调用者都能合法拥有内部对象权限时，才适合使用 INVOKER。

问：能不能直接把 DEFINER 改成 root？
答：不应这样处理。优先使用专用、最小权限的服务账号；高权限定义者会让任何拥有 EXECUTE 的调用者间接获得更大的数据访问能力。