一、MySQL 删除存储过程的基本语法
1. 标准删除命令
DROP PROCEDURE [IF EXISTS] procedure_name;
`procedure_name`：表示需要删除的 MySQL 存储过程名称。
注意：存储过程名称后面不需要加参数列表或括号，这一点与调用方式（`CALL proc_name()`）以及创建定义时的写法不同。
`IF EXISTS`：这是一个可选子句。如果指定了它，当目标存储过程不存在时，MySQL 不会直接报错，而是返回警告信息。实际开发中非常推荐使用该写法，因为它能让删除语句在存储过程不存在时依然安全执行，尤其适合部署脚本、自动化运维脚本和数据库迁移场景。
2. 使用示例
安全删除（推荐）：如果存在 'ShowStuScore' 存储过程则执行删除，不存在则直接忽略
DROP PROCEDURE IF EXISTS ShowStuScore;
不安全删除：如果 'ShowStuScore' 过程不存在，执行以下语句会直接报错：
ERROR 1305 (42000): PROCEDURE test.ShowStuScore does not exist DROP PROCEDURE ShowStuScore;
二、删除存储过程的影响与注意事项
1. 依赖关系：在删除 MySQL 存储过程之前，必须先确认是否有其他数据库对象（如其他存储过程、函数、触发器，或者业务应用程序）依赖它。若未检查清楚就直接删除，可能会导致相关功能在运行时出现异常或报错。
检查方法：遗憾的是，MySQL 本身并没有提供特别完善的依赖关系追踪机制。通常需要结合以下方式排查：
人工检查相关代码，包括其他存储过程定义以及应用程序中的调用逻辑。
查询 `information_schema.ROUTINES` 表，尝试通过搜索 `ROUTINE_DEFINITION` 字段，查看是否存在其他过程调用了该过程名称。
先在测试环境或预发布环境中做完整验证，确认不会影响现有业务。
2. 权限要求：执行删除操作的用户必须对目标存储过程拥有 `DROP` 权限，否则无法成功删除。
3. 不可恢复：删除存储过程属于永久性操作。一旦执行完成，该过程定义会从数据字典中移除；如果事先没有做好备份，后续通常无法直接恢复。
三、如何确认存储过程已删除成功
删除操作执行成功后，MySQL 通常会返回 `Query OK, 0 rows affected`。不过，为了进一步确认删除结果是否真正生效，建议再通过以下方式进行验证：
1. 查询 `information_schema.routines` 系统表（常用且可靠的方法）
这是确认 MySQL 存储过程是否已被删除的可靠方法之一。
查询指定名称的存储过程是否仍然存在
SELECT * FROM information_schema.routines
WHERE routine_name = 'ShowStuScore'
AND routine_type = 'PROCEDURE';
如果查询结果返回 `Empty set`，说明该存储过程已经删除成功。
2. 使用 `SHOW` 命令检查
检查过程状态列表中是否仍然存在该存储过程
SHOW PROCEDURE STATUS LIKE 'ShowStuScore';
尝试查看其定义（如果目标过程不存在，MySQL 会报错）
SHOW CREATE PROCEDURE ShowStuScore;
四、删除存储过程的最佳实践与工作流程
1. 备份先行：在删除任何数据库对象之前，尤其是可能被多个模块复用的存储过程，一定要先备份其定义。最直接的方法就是使用 `SHOW CREATE PROCEDURE` 命令，将完整的创建语句导出并保存。
SHOW CREATE PROCEDURE ShowStuScore G
将输出结果中的 'Create Procedure' 字段内容复制并保存到 SQL 文件中，便于后续恢复或审计。
2. 统一使用 `IF EXISTS`：建议在所有删除存储过程的 SQL 脚本中都加上 `IF EXISTS` 子句，以提升脚本兼容性和执行稳定性。
3. 纳入开发流程：删除操作应当作为数据库变更脚本的一部分进行记录，并与应用版本发布保持同步，确保程序代码与数据库对象结构一致。
4. 先做模拟测试：正式在生产环境删除存储过程之前，建议先在测试环境中执行并验证，确认不存在隐藏依赖关系或业务影响后再上线操作。
