修改存储过程时CALL失败的直接原因是MySQL对存储过程加元数据锁（MDL），若另一会话执行ALTER/DROP/CREATE操作，会导致定义缺失窗口，使运行中CALL因找不到过程或权限校验失败而报错。
修改存储过程时会话仍在运行，CALL 突然失败
直接原因：MySQL 在执行 CALL proc_name() 时，会锁定该存储过程的元数据（metadata lock，MDL）。如果另一个会话此时用 ALTER PROCEDURE 或 DROP/CREATE 修改它，DDL 操作会等待 MDL 写锁，而正在运行的 CALL 会话一旦尝试读取已失效或正在重写的定义，就可能报错 ERROR 1305 (42000): PROCEDURE db_name.proc_name does not exist 或更隐蔽的 ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger（尤其在含事务/临时表的场景）。
ALTER PROCEDURE 不是原子操作，中间态会暴露
MySQL 的 ALTER PROCEDURE 实际分三步：删旧定义 → 写新定义 → 刷新缓存。这期间存在极短但真实存在的“定义缺失窗口”。若原会话恰好在此刻执行到内部嵌套调用、或触发器中再次引用该过程，就会因找不到对象而中断。
- 不建议在业务高峰期执行
ALTER PROCEDURE，哪怕只改注释 -
SHOW CREATE PROCEDURE查出的DEFINER和SQL SECURITY若被意外覆盖（比如导出重建时漏了DEFINER），运行中会话可能因权限校验失败退出 - 云数据库（如阿里云 RDS、腾讯云 CDB）对
mysql.proc表强制只读，任何绕过ALTER直接写表的操作都会导致后续CALL报错ERROR 1294 (HY000)
真正安全的热更新方式只有两种
想改又不让活会话崩，只能避开元数据锁冲突点：
- 用
RENAME PROCEDURE old_proc TO temp_old; CREATE PROCEDURE new_proc ...，再让应用逐步切流量——前提是应用层支持动态切换过程名 - 把逻辑拆进函数或视图，只改函数体（
ALTER FUNCTION锁粒度更细，且不影响已启动的存储过程执行流） - 绝对不要在
CALL过程中执行ALTER；如必须紧急修复，先KILL掉所有正在调用该过程的会话（查information_schema.processlist中INFO LIKE 'CALL%proc_name%'），再改
容易被忽略的隐性依赖
你以为只改了一个存储过程？其实它可能依赖其他对象，而那些对象没同步更新：
- 过程里调用了
func_x()，你改了proc_y，但func_x的DEFINER已失效——运行中会话第一次调用func_x时才报错，不是改proc_y的那一刻 - 过程内用了临时表
tmp_log，而新版本里删了该表创建语句，旧会话在第二次循环中尝试INSERT INTO tmp_log就会失败 - 字符集变更（比如库从
utf8mb4_bin改成utf8mb4_0900_bin）后重建过程，但变量排序规则仍沿用旧库默认值，导致=比较报ERROR 1267
