MySQL 本身不支持“在线修改存储过程体”的原子操作，所谓“不中断服务”不是靠单条命令实现的，而是靠流程设计和权限控制来规避停用窗口。核心矛盾在于：DROP PROCEDURE 和 CREATE PROCEDURE 是两个独立语句，中间存在不可消除的间隙——哪怕只有毫秒级，调用方也可能报 PROCEDURE does not exist。
为什么 ALTER PROCEDURE 不能改逻辑体
MySQL 的 ALTER PROCEDURE 只能修改元数据特征（如 SQL SECURITY、COMMENT、MODIFIES SQL DATA），不能动 BEGIN...END 里的任何 SQL。这是官方明确限制，不是版本问题。
- 8.0.16+ 支持
ALTER PROCEDURE ... COMMENT = 'xxx'或SQL SECURITY DEFINER，但如果你执行ALTER PROCEDURE p1 BEGIN SELECT 1; END，会直接报语法错误 -
SHOW CREATE PROCEDURE p1输出里，CREATE DEFINER=...后面紧跟着的是完整定义，ALTER永远不会碰这部分 - 试图绕过用
REPLACE或拼接字符串生成新CREATE语句，本质仍是重建，没解决间隙问题
如何做到“业务无感”的平滑切换
关键不是避免重建，而是让重建不暴露给调用方。推荐用同名别名 + 原子重命名方案，依赖 MySQL 对 RENAME 的事务安全保证：
- 先创建带版本后缀的新过程，比如
showstuscore_v2，逻辑完全验证通过 - 用
RENAME PROCEDURE showstuscore TO showstuscore_old, showstuscore_v2 TO showstuscore—— 这是原子操作，MySQL 内部一次性更新元数据，调用方在任意时刻看到的都是完整可用的过程名 - 旧过程留着观察 24 小时，确认无误后再
DROP PROCEDURE showstuscore_old - 注意：该方案要求 MySQL ≥ 5.7.6（
RENAME PROCEDURE引入版本），且用户需有ALTER ROUTINE权限
权限与版本陷阱必须提前检查
即使流程再严谨，权限或版本不匹配也会导致切换失败：
- 执行
RENAME PROCEDURE需要ALTER ROUTINE权限，仅EXECUTE不够；检查方式：SHOW GRANTS FOR CURRENT_USER - MySQL 5.7 以下不支持
RENAME PROCEDURE，只能退回到传统重建法，此时必须接受短时不可用，或改用代理层（如 ProxySQL）做路由切换 - 如果过程被其他存储过程或事件（
EVENT）硬编码调用，重命名后它们会立刻失败，需同步更新所有上游依赖 -
DEFINER用户不存在时，新建过程可能无法执行（尤其跨环境迁移），建议显式指定DEFINER = CURRENT_USER
真正难的从来不是写对那几行 SQL，而是确保上下游所有依赖都按预期响应重命名后的过程名——这需要在测试环境完整走通调用链，而不是只验证存储过程自己能跑通。
