直接更新mysql.proc表是修改存储过程DEFINER的唯一高效方式，因ALTER PROCEDURE不支持修改DEFINER，视图则必须重建；操作需满足权限、用户存在、格式正确及WHERE限定等硬条件。
直接改 mysql.proc 表是最快、最可控的方式，但视图不能这么干——它没对应系统表，必须重建；而存储过程在 MySQL 8.0 中仍不支持 ALTER PROCEDURE DEFINER=...，所以别指望一条命令通吃。
为什么不能用 ALTER PROCEDURE 修改 DEFINER
MySQL 8.0 虽然支持 ALTER PROCEDURE（自 8.0.16 起），但它只允许改 SQL SECURITY、COMMENT、DETERMINISTIC 等属性，**DEFINER 不在可修改列表里**。你执行：
ALTER PROCEDURE my_proc DEFINER = 'new_user'@'%';
会直接报错 ERROR 1064 (42000)：语法错误。官方文档明确列出该语句不接受 DEFINER 子句。
常见误操作还包括：
- 用
CREATE OR REPLACE PROCEDURE替换——会丢失原始SQL SECURITY INVOKER设置（默认变回DEFINER） - 忽略注释和换行格式，导致后续 diff 或审计困难
- 没检查新
DEFINER用户是否存在，UPDATE 后调用才暴露ERROR 1449
安全批量更新存储过程的 DEFINER（推荐）
直接更新 mysql.proc 是唯一高效方式，但必须满足几个硬条件：
- 当前用户有
UPDATE权限 onmysql.proc（通常只有root或带SYSTEM_USER权限的账号） - 目标用户（如
'app_user'@'%'）已存在，否则调用时报The user specified as a definer does not exist -
definer字段是CHAR(77)，值必须带单引号且完整，例如'app_user'@'%'，不能写成app_user@%或`app_user`@`%` - 务必加
WHERE限定库名，避免跨库误改：WHERE db = 'mydb' AND type = 'PROCEDURE'
执行示例：
UPDATE mysql.proc SET definer = '''app_user''@''%''' WHERE db = 'mydb' AND type = 'PROCEDURE';
注意：三个单引号是 MySQL 字符串内嵌单引号的标准写法，不是笔误。改完无需 FLUSH PRIVILEGES，但已有连接缓存的元信息不会自动刷新，建议滚动应用连接池。
视图的 DEFINER 必须重建，不能 UPDATE
INFORMATION_SCHEMA.VIEWS 是只读视图，没有底层可写表对应，所以无法像存储过程那样直接 UPDATE。你得生成 ALTER VIEW 语句并逐条执行：
SELECT CONCAT("ALTER DEFINER = 'app_user'@'%' SQL SECURITY DEFINER VIEW ", TABLE_SCHEMA, ".", TABLE_NAME, " AS ", VIEW_DEFINITION, ";")
FROM INFORMATION_SCHEMA.VIEWS
WHERE DEFINER != 'app_user@%';
执行结果是一堆 ALTER VIEW ... AS SELECT ... 语句，复制执行即可。关键点：
-
ALTER VIEW要求重写整个AS子句，不能只改定义者 - 必须保留原
SQL SECURITY设置（DEFINER或INVOKER），否则默认变成DEFINER - 如果视图依赖其他对象（比如函数），而新
DEFINER没权限访问，执行ALTER VIEW时就会失败，不是调用时才报 - 某些 MySQL 8.0.33+ 版本在
sql_mode=STRICT_TRANS_TABLES下对DEFINER格式校验更严，错误格式（如漏单引号）会导致语句直接被拒
最容易被忽略的细节
很多人以为改完 DEFINER 就万事大吉，其实还有两个隐形雷：
-
mysql.proc表里的security_type字段（值为'DEFINER'或'INVOKER'）是只读的，UPDATE 它完全无效——它只在创建时固化。想切安全模式？只能重建过程。 - 触发器、事件、函数也各自有
DEFINER，但它们没统一修改入口：触发器和事件必须DROP + CREATE，函数也得走mysql.proc（同存储过程），别漏掉。
批量操作前，先用 SELECT 预查一遍范围，比盲目 UPDATE 安全得多。
