DROP FUNCTION 是 MySQL 中直接删除存储函数的唯一 SQL 语句，一旦执行成功，函数会立即从元数据中移除。操作前需要具备 ALTER ROUTINE 权限，并提前确认相关依赖关系；为了避免因函数不存在而导致报错，通常建议结合 IF EXISTS 一起使用。删除完成后，还可以通过 INFORMATION_SCHEMA.ROUTINES 或 SHOW FUNCTION STATUS 检查结果，确认存储函数是否已经删除成功。
DROP FUNCTION 是唯一可以直接删除存储函数的命令，没有所谓“软删除”机制，也不存在后台异步清理流程——只要执行成功，函数就会从 MySQL 元数据中彻底移除，通常也不需要额外进行空间释放操作。
执行 DROP FUNCTION 前必须确认权限和依赖
MySQL 对删除存储函数的权限要求非常明确：用户必须对函数所在数据库拥有 ALTER ROUTINE 权限。这里需要特别注意，所需权限不是 DELETE，也不是 DROP。如果权限不足，系统会直接返回错误：ERROR 1370 (42000): alter routine command denied to user。
另外，还有一个在实际运维中很容易被忽略的问题——函数依赖关系。如果其他存储过程、视图或触发器内部调用了这个函数，那么删除函数后，这些对象本身不会自动被删除，看起来依旧存在；但在下一次实际执行时，就会立即报错：ERROR 1305 (42000): FUNCTION db_name.func_name does not exist。
因此，更安全、更稳妥的做法是先把依赖项检查清楚：
- 检查
INFORMATION_SCHEMA.ROUTINES中是否有其他例程引用该函数（通常需要手动搜索函数名，因为 MySQL 本身并不提供完整的依赖关系图） - 在应用程序代码或 SQL 脚本中全局检索函数名，尤其要重点关注
SELECT、WHERE、ORDER BY等常见使用场景 - 生产环境中建议选择业务低峰期执行操作，并提前备份函数定义：
SHOW CREATE FUNCTION func_name
IF EXISTS 不是可选糖衣，而是防错刚需
如果不加 IF EXISTS，当目标函数不存在时，删除语句会直接失败，并中断后续 SQL 执行流程，例如在批量删除脚本中会特别明显。加上之后，即使函数不存在，MySQL 也会返回 Query OK，从而避免无谓报错。
不过也要注意：IF EXISTS 只能跳过“函数不存在”的错误，无法忽略权限不足或语法错误等其他问题。
正确写法：DROP FUNCTION IF EXISTS my_calc_total;
错误写法：DROP FUNCTION my_calc_total IF EXISTS;（IF EXISTS 必须紧跟在 DROP FUNCTION 之后，不能放在语句末尾）
删完怎么验证？别只信 “Query OK”
MySQL 返回的 Query OK 仅表示语句解析通过且权限校验通过，并不建议只凭这一提示判断函数是否一定已经消失。更可靠的验证方式是直接检查元数据：
- 查询
INFORMATION_SCHEMA.ROUTINES：SELECT * FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_NAME = 'my_calc_total' AND ROUTINE_SCHEMA = 'your_db';—— 只有返回空结果时，才能确认该存储函数已被彻底删除 - 查看
SHOW FUNCTION STATUS：SHOW FUNCTION STATUS LIKE 'my_calc_total';—— 如果没有对应记录，通常说明函数已经不存在 - 不建议使用
SHOW CREATE FUNCTION来做验证，因为当函数不存在时，它会直接报错，反而不利于自动化脚本或批处理流程
删除后物理空间不会立即回收
存储函数定义通常保存在 mysql.proc 表（旧版本）或通过 INFORMATION_SCHEMA.ROUTINES 体现（新版本）中，这些都属于系统元数据。删除函数本身不会带来明显的大块磁盘空间释放，因此通常不需要额外执行 OPTIMIZE TABLE，也没必要为此专门重启 MySQL 服务。
唯一需要留意的是：如果该函数内部曾使用临时表或较大的变量，并且之前被高频调用，可能会残留少量运行时内存缓存——但这属于执行过程中的运行时现象，与 DROP FUNCTION 删除动作本身无直接关系，后续在服务重启或缓存淘汰后会自动清理。
