MySQL 5.7及更早版本中，DROP PROCEDURE IF EXISTS 不完全可靠，须手动查 INFORMATION_SCHEMA.ROUTINES 并指定 ROUTINE_SCHEMA 和 ROUTINE_TYPE='PROCEDURE' 确认存在性，且推荐显式使用 db_name.proc_name 语法以避免作用域错误。
检查 INFORMATION_SCHEMA.ROUTINES 判断存储过程是否存在
MySQL 不支持 DROP PROCEDURE IF EXISTS 在所有版本中都可靠（尤其 5.7 及更早），所以得手动查。最稳妥的方式是查系统表 INFORMATION_SCHEMA.ROUTINES，它记录了所有存储过程和函数的元信息。
注意：必须指定正确的 ROUTINE_SCHEMA（即数据库名），否则可能跨库误判；ROUTINE_TYPE 要等于 'PROCEDURE'，避免把函数也混进来。
常见错误是只查 ROUTINE_NAME 而忽略库名，导致在多库环境下判断失效。示例查询：
SELECT COUNT(*) FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA = 'your_database_name' AND ROUTINE_NAME = 'your_procedure_name' AND ROUTINE_TYPE = 'PROCEDURE';
用 DROP PROCEDURE IF EXISTS 的实际兼容性边界
DROP PROCEDURE IF EXISTS 从 MySQL 5.0.3 就存在，但有隐含前提：当前会话默认数据库（USE db_name）必须与目标过程所在库一致，或显式写全名 db_name.procedure_name，否则在某些旧客户端或严格 SQL 模式下会报 ERROR 1305 (42000): PROCEDURE db_name.procedure_name does not exist —— 即使它其实存在。
因此建议始终显式带上数据库名：
DROP PROCEDURE IF EXISTS your_database_name.your_procedure_name;
如果不确定当前默认库，别依赖隐式上下文；也不要用 IF NOT EXISTS 来“兜底”逻辑，它不解决权限或作用域问题。
创建前确保 DELIMITER 已重设
这是高频翻车点：很多教程复制的创建语句自带 DELIMITER $$，但如果你在同一个会话里反复执行“删+建”，上一次执行没重置分隔符，会导致后续 CREATE PROCEDURE 语句被截断或语法报错（比如 ERROR 1064 (42000) 提示 near ‘END’）。
实操建议：每次创建前先执行 DELIMITER ; 清场，再按需改分隔符。完整安全流程如下：
- 执行
DELIMITER ; - 执行
DROP PROCEDURE IF EXISTS your_db.your_proc; - 执行
DELIMITER $$ - 执行
CREATE PROCEDURE your_db.your_proc(...) BEGIN ... END$$ - 最后再执行
DELIMITER ;恢复（方便后续单条命令）
自动化脚本里慎用 CONCAT + PREPARE 动态删过程
有人想用动态 SQL 组装 DROP 语句来绕过硬编码库名，例如：
SET @sql = CONCAT('DROP PROCEDURE IF EXISTS ', DATABASE(), '.', 'my_proc'); PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt;
这看似灵活，但存在两个硬伤：一是 DATABASE() 返回的是当前默认库，不是目标过程所在库（容易错删）；二是预处理语句不能执行 DROP / CREATE 这类非 SELECT 语句（MySQL 8.0+ 才部分支持，5.7 会直接报错 ERROR 1295 (HY000): This command is not supported in the prepared statement protocol yet）。
所以除非你明确控制环境为 MySQL 8.0+ 且确认库名上下文绝对一致，否则老实用静态语句 + 显式库名更稳。
真正容易被忽略的是权限——DROP 和 CREATE 需要 ALTER ROUTINE 权限，仅 CREATE ROUTINE 不够；而很多自动化部署账号只被授予后者，结果删不掉、建不成，报错却只显示“access denied for routine”，不提示缺哪个具体权限。
