MySQL 8.0 不支持直接重命名存储过程，必须通过“删除旧过程 + 重建新过程”实现；官方从未实现 RENAME PROCEDURE 语法，ALTER PROCEDURE RENAME 也非法，系统表 mysql.proc 已移除，元数据统一存于只读数据字典。
MySQL 8.0 不支持直接重命名存储过程，RENAME PROCEDURE 是无效语法，执行会报错 ERROR 1064 (42000)。 必须用“删除旧过程 + 重建新过程”的方式实现逻辑重命名，且关键细节稍有疏忽就会导致权限失败或调用中断。
为什么 RENAME PROCEDURE old TO new 会报错
MySQL 官方从未实现 RENAME PROCEDURE 语句。所谓“可用”的说法多源于混淆了 MySQL 5.7 以前的非官方补丁、误读文档，或把 RENAME TABLE 的能力错误迁移到过程上。在 8.0 中明确不识别该语法，服务器直接拒绝解析。
- 执行
RENAME PROCEDURE p_old TO p_new→ 报错：ERROR 1064 (42000): You have an error in your SQL syntax -
ALTER PROCEDURE p_old RENAME TO p_new同样非法，无此语法 - 试图更新系统表
mysql.proc（如老资料所提）在 8.0 中已不可行：该表被移除，元数据统一存于data_dictionary，且只读
安全重命名的最小操作链：从导出到验证
核心是保证 DEFINER、SQL SECURITY、参数签名、主体逻辑一字不差地迁移，仅改过程名。跳过任意一步都可能让新过程无法执行或权限不足。
- 先导出原定义：
SHOW CREATE PROCEDURE `old_proc`;—— 注意反引号包裹，避免关键字冲突 - 人工检查输出中的
DEFINER（如DEFINER=`admin`@`%`）和SQL SECURITY（DEFINER或INVOKER），这两项必须显式写进新CREATE语句 - 复制整个
CREATE PROCEDURE块，把开头的`old_proc`替换为`new_proc`，其余包括分隔符、参数列表、BEGIN/END 结构全部保留 - 执行前加
DROP PROCEDURE IF EXISTS `old_proc`;，防止后续重建失败时残留旧过程 - 验证后，立刻用
CALL `new_proc`(...)测试，别依赖“看起来建成功了”
容易被忽略的 DEFINER 权限陷阱
如果你没在 CREATE PROCEDURE 里显式写 DEFINER，MySQL 会默认设为当前登录用户，而原过程可能是 DEFINER=`sysadmin`@`localhost`。一旦新过程以当前用户身份运行，却要访问 sysadmin 才有权查的表，就会报 ERROR 1449 (HY000): The user specified as a definer does not exist 或权限拒绝。
- 正确做法：从
SHOW CREATE输出中完整复制DEFINER=`xxx`@`yyy` SQL SECURITY xxx子句 - 如果原
DEFINER用户已不存在，要么先重建该用户，要么改用SQL SECURITY INVOKER并确保调用者有足够权限 - 测试时用与生产调用方一致的账号连接，否则权限问题可能被掩盖
原子切换方案（适合高可用场景）
如果过程正在被应用频繁调用，DROP 期间会有短暂不可用窗口。此时应放弃直接重命名，改用“双过程并存 + 切换”：
- 新建过程命名为
`new_proc_v2`，完整复刻逻辑并测试通过 - 用
RENAME PROCEDURE `old_proc` TO `old_proc_bak`, `new_proc_v2` TO `old_proc`;—— 这条RENAME PROCEDURE在 MySQL 8.0.30+ 才支持，且仅限同库内两个已存在过程互换名字 - 确认切换后立即验证结果一致性，再删掉
`old_proc_bak` - 注意：
RENAME PROCEDURE是原子操作，但前提是两个过程都已存在且签名兼容；它不校验逻辑，只改元数据
真正麻烦的从来不是“怎么写那几行 SQL”，而是你不知道原过程在哪个 EVENT 里被定时调用、有没有 JDBC 里硬编码的 {CALL old_proc()}、或者它的 DEFINER 其实依赖一个已下线的 LDAP 账户。重命名前花十分钟看一遍依赖，比花两小时排查凌晨三点的告警更省事。
