使用存储过程执行 SELECT、UPDATE、INSERT 的任何禁忌症答案

【问题标题】：Any contraindication of using Stored Procedures performing SELECT, UPDATE, INSTERT使用存储过程执行 SELECT、UPDATE、INSERT 的任何禁忌症
【发布时间】：2009-03-20 09:27:44
【问题描述】：

我正在使用一个 SP 执行所有 CRUD 操作
所以，基本上我正在执行相同的 SP，具体取决于所需的操作：

例如

-- for select
exec USP_ORDER @MODE='S', @ORDER_DATE='2009/01/01'
-- for update
exec USP_ORDER @MODE='U', @other_params
-- for insert
exec USP_ORDER @MODE='I', @other_params
-- for delete
exec USP_ORDER @MODE='D', @ID=100

感谢我每 1 个业务对象只有 1 个 SP，这使我的数据库保持有序。但最近我遇到了性能问题。鉴于我的问题：
这种方法正确吗？它会对性能/适当的执行产生影响吗？计划？

【问题讨论】：

标签： sql-server performance stored-procedures

【解决方案1】：

由于可能缓存“错误”的查询计划，它可能会对性能产生影响。查看主题'parameter sniffing' 和query plan caching。

编辑：针对 John 的评论，您还可以让顶级 SP 决定调用哪个 CRUD SP，然后每个人都会获得自己的缓存查询计划。

【讨论】：

嗨 Mitch，我认为在 SQL 2005 及更高版本中，存储过程中的每个批处理/语句都有自己的执行计划？这是为了帮助重新编译，以便在必要时仅重新编译特定步骤而不是整个过程？.....
那么参数嗅探肯定会成为所有存储过程的潜在问题，而不仅仅是具有多种类型 crud 操作的存储过程？
@John Sansom：没错。海报暗示他有一个 SP 执行所有操作。
@Mitch：感谢您的澄清！

【解决方案2】：

我认为这更像是一个编码/设计偏好问题。

就个人而言，我非常喜欢保持简单，因此我建议您将操作分解为单独的存储过程。

这将更加透明，也有助于您将来可能需要做的任何性能调整，即如果您的更新过程/逻辑执行缓慢，您可以立即将其隔离为原因，而如果逻辑是具有不同 CRUD 操作的较大过程，问题的根本原因不会那么明显。

【讨论】：

【解决方案3】：

我也喜欢简化（如果可能的话）。

但我决定采用这种方式的原因：目前我有大约 80 个 SP 如果我按它们所服务的功能划分所有（例如 USP_Sample_Insert、USP_Sample_Select1、USP_Sample_Select2、 USP_Sample_Delete) 我将有大约 400 个 SP！

如果 SP 实例对我来说是一场噩梦，那么管理、导航、更新、同步如此大量的参数。

对我来说 - 唯一合理的情况是性能......

【讨论】：