删除重建存储过程而非直接修改是否有益？其规避缓存的说法是否可信？

嘿，这个问题挺接地气的，我来帮你拆解清楚：

一、“删除重建避免缓存”的说法是否属实？ #

答案是不属实，至少在当下主流的数据库（比如SQL Server、MySQL、PostgreSQL）里完全站不住脚。

当你用ALTER PROCEDURE直接修改存储过程时，数据库会自动把旧的执行计划缓存标记为无效，后续调用时会自动生成新的执行计划。根本不需要通过删除再重建的方式来规避缓存问题。

前任经理的说法大概率是来自非常老旧的数据库版本（比如十几年前的SQL Server 2000早期版本），或者是他混淆了其他场景的操作逻辑——放在现在，这个做法完全是多余的。

二、删除重建相较于直接修改有没有益处？ #

几乎没有，反而会带来一堆不必要的风险：

• 权限丢失风险：删除存储过程后，之前给这个过程配置的所有权限会被清空，重建后得重新逐一配置，非常折腾。
• 依赖关系断裂：如果这个存储过程被其他对象（比如触发器、关联存储过程、视图）依赖，删除操作可能直接报错，或者导致依赖对象在调用时直接失败；而ALTER操作不会影响现有依赖关系。
• 原子性缺失：DROP和CREATE是两个独立的操作，中间如果有其他会话尝试调用这个存储过程，会直接触发“对象不存在”的错误；而ALTER是原子操作，修改过程中不会出现对象不可用的空档期。
• 历史记录丢失：部分数据库会保留存储过程的修改历史，直接ALTER能留存这些记录，删除重建则会清空所有历史痕迹。

当然，如果是极端场景（比如你需要完全重置存储过程的所有系统元数据属性），可能偶尔会用到删除重建，但这种情况极其罕见，日常开发中完全没必要这么折腾。

内容的提问来源于stack exchange，提问作者Ageis