MySQL不支持批量DROP PROCEDURE，需逐条安全删除：先识别失效过程（查依赖、保留字、函数），再生成带反引号的DROP语句逐行执行并验证，最后检查事件、其他过程及应用调用影响。
直接 DROP PROCEDURE 批量执行会出错
MySQL 不支持 DROP PROCEDURE IF EXISTS p1, p2, p3 这种多过程一次性删除语法。试图用脚本拼接 DROP PROCEDURE 并批量执行，容易触发以下问题：
• 某个过程正被其他会话调用中，DROP 会卡住或报 ERROR 1305 (42000): PROCEDURE db.p1 does not exist（其实是被锁，不是真不存在）
• 过程名含特殊字符或保留字（如 rank、json），没加反引号就执行 DROP PROCEDURE rank 直接语法错误
• 8.0 中用户权限粒度更细，执行者若无 ALTER ROUTINE 权限，单条 DROP 就失败，批量更难定位哪条挂了
先安全识别哪些存储过程真该删
别靠“很久没调用”主观判断。失效过程通常有三类典型特征，要结合 INFORMATION_SCHEMA.ROUTINES 和运行时验证：
• 调用了已删表/视图：查 ROUTINE_DEFINITION 是否含 FROM old_table 或 JOIN deleted_view，再用 SELECT COUNT(*) FROM old_table 实测确认
• 含 MySQL 8.0 新保留字：执行 SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_DEFINITION REGEXP '(rank|json|window|partition|group|order)\b' AND ROUTINE_TYPE = 'PROCEDURE';，结果里的过程名必须加反引号再删
• 依赖已删函数或自定义函数：检查 ROUTINE_DEFINITION 是否调用 my_encrypt() 类函数，再查 SELECT * FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_NAME = 'my_encrypt' 确认是否存在
分步执行删除，避免锁表和中断
用生成 SQL + 逐条执行代替“一键脚本”。关键动作必须手动确认：
• 先导出待删列表：SELECT CONCAT('DROP PROCEDURE `', ROUTINE_SCHEMA, '`.`', ROUTINE_NAME, '`;') AS drop_sql FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA = 'your_db' AND ROUTINE_TYPE = 'PROCEDURE' AND ...;
• 复制结果，在客户端里逐行粘贴执行，每条后跟 SELECT @@error_count; 判断是否成功
• 遇到 ERROR 1305，立刻查 SHOW CREATE PROCEDURE `p_name` 看是否存在、是否被重命名
• 遇到权限错误，临时加权限：GRANT ALTER ROUTINE ON your_db.* TO 'user'@'host'; FLUSH PRIVILEGES;，删完即 revoke
删完必须验证下游影响
存储过程常被事件、定时任务、应用代码硬编码调用，删完不验证等于埋雷：
• 查事件：SELECT EVENT_SCHEMA, EVENT_NAME, EVENT_DEFINITION FROM INFORMATION_SCHEMA.EVENTS WHERE EVENT_DEFINITION LIKE '%CALL your_proc%';
• 查其他过程体：SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_DEFINITION FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_DEFINITION LIKE '%your_proc%' AND ROUTINE_TYPE = 'PROCEDURE';
• 检查应用日志关键词，如 "CALL backup_old_data" 是否还在报 PROCEDURE doesn't exist
• 8.0 的角色机制会让问题更隐蔽：如果该过程曾被某个角色授予执行权，删过程后角色权限残留不会报错，但新用户继承角色时调用会失败
