DROP PROCEDURE IF EXISTS 和 DROP FUNCTION IF EXISTS 可避免对象不存在报错，但无法规避权限不足、依赖断裂、误删生产对象等风险；删除前须确认库环境、检查依赖（ROUTINES/VIEWS）、验证权限，删除后须查 information_schema.ROUTINES 确认清除。
直接用 DROP PROCEDURE IF EXISTS 和 DROP FUNCTION IF EXISTS 是最安全的起点，但“安全”不只靠加 IF EXISTS —— 它掩盖不了权限缺失、依赖断裂或误删生产对象的问题。
为什么 IF EXISTS 不能代替风险评估
加 IF EXISTS 确实能避免“函数不存在”的报错，但它不会阻止以下真实故障：
- 执行用户没有
DROP权限 → 报错ERROR 1227 (42000): Access denied - 其他存储过程在定义里硬编码调用了该函数 → 删除后调用时才暴露
ERROR 1305 (42000): FUNCTION db.func_name does not exist - 应用代码（如 Java/Python）里拼接了该函数名用于查询 → 运行时报 SQL 错误，而非建表/删表级错误，更难定位
-
IF EXISTS对大小写敏感（取决于系统变量lower_case_table_names），drop function if exists MyFunc在 Linux 上可能不生效
删除前必须验证的三件事
别跳过这三步，否则恢复成本远高于预防成本：
- 确认当前连接的是目标数据库：
SELECT DATABASE();，避免在test库执行却想删prod库的对象 - 查依赖：MySQL 没有原生依赖图，只能人工扫描
information_schema.ROUTINES中的ROUTINE_DEFINITION字段：SELECT ROUTINE_NAME, ROUTINE_TYPE FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'your_db' AND ROUTINE_DEFINITION LIKE '%func_name%';
- 检查是否被视图引用：
SELECT TABLE_NAME FROM information_schema.VIEWS WHERE TABLE_SCHEMA = 'your_db' AND VIEW_DEFINITION LIKE '%func_name%';
删除后怎么确认真没了
光看 Query OK 不够，MySQL 的 DROP 成功只表示语句执行无语法/权限错误，不代表对象已从元数据中清除：
- 查
information_schema.ROUTINES是唯一可靠方式：SELECT COUNT(*) FROM information_schema.ROUTINES WHERE ROUTINE_NAME = 'proc_name' AND ROUTINE_SCHEMA = 'your_db' AND ROUTINE_TYPE = 'PROCEDURE';
返回0才算真正删除 -
SHOW PROCEDURE STATUS LIKE 'proc_name'或SHOW FUNCTION STATUS LIKE 'func_name'可能返回空结果，但不如查ROUTINES表稳定（尤其跨 MySQL 版本） - 不要依赖
SHOW CREATE PROCEDURE proc_name—— 它报错ERROR 1305虽然说明没了，但错误本身会中断脚本流
最容易被忽略的是：MySQL 不记录谁删了什么、什么时候删的。如果团队共用高权限账号，建议把关键 DROP 操作包装进带日志的封装脚本，或者启用 general_log（仅调试期）—— 否则出问题时，你连“是不是自己删的”都得靠猜。
