存储过程选择 VS 从外部连接中选择答案

【问题标题】：Stored procedure select VS select from external connection存储过程选择 VS 从外部连接中选择
【发布时间】：2021-12-29 17:27:05
【问题描述】：

我试图找出使用存储过程而不是来自外部连接的 SQL 查询的优缺点，但我找不到任何直接的比较。

【问题讨论】：

您能澄清一下“来自外部连接”的含义吗？我认为您的意思是 SP 和 Query 都来自某个外部应用程序，对吗？
老实说，我真的很担心我的问题是什么原因，这对于真正大规模项目的决策来说非常重要，它给出了反对票。毫无疑问，StackOverflow 是一个如今提出问题会导致非常奇怪的结果的地方。即使是“关闭”投票！？有趣的！我想听听这背后的解释。

【解决方案1】：

使用存储过程而不是来自外部连接的 SQL 查询有什么好处？

存储过程可能很复杂。非常复杂。他们可以做事这是单个 SQL 查询无法做到的。（执行 Block 放在一边。）
他们有自己的一组授权，因此他们可以做当前用户可以做的事情根本做不到。
Firebird 优化器并没有那么糟糕，但显然复杂的查询需要更多时间进行优化，而且结果仍然可能不是最理想的。使用命令式语言，程序员可以将复杂的查询拆分为一组更简单的查询，从而使Data Access Paths 更具可预测性。

对于小体积，它们之间是否存在执行速度差异和大容量输出？

没有。

对数据库管理也有什么好处吗？

这取决于您所说的“数据库管理”以及您想到的好处。最有可能 - 没有。

【讨论】：

【解决方案2】：

使用存储过程而不是来自外部连接的 SQL 查询有什么好处？

就执行而言，一个好处是存储过程存储其查询计划，而动态 sql 查询计划不会被存储，并且必须在每次执行查询时计算。

对于小容量和大容量输出，它们之间是否存在执行速度差异？

一旦计算出查询计划，不，没有速度差异。

对数据库管理也有什么好处吗？

这是非常主观的！过去，我在一个所有数据库访问都通过存储过程的地方工作，这样他们就可以锁定对 SP 的访问。我工作过的其他地方根本没有使用存储过程，因为它们通常不在源代码控制范围内，并且对于不是 SQL 专家的开发人员来说是个问题。此外，跨多个系统的业务逻辑可能会成为一个真正的问题。

【讨论】：

动态查询？你的意思是 ad-hoc SQL——这些计划也被缓存了，所以这根本不是真的。
在 Firebird 中不存储执行计划。存储过程从 BLR 编译并在首次加载时进行优化。 DSQL 在准备时被编译和优化。
@Stu 你是对的，如果你在缓存保留期限内一遍又一遍地执行相同的 sql，它将重用缓存。还有一些技巧可以增加查询计划在缓存中的停留时间，例如参数化查询。查询计划使用的频率越高，它的保留时间就越长。
Firebird 也没有查询计划缓存。
一个额外的考虑是加入。我不确定通过外部连接进行选择是否会像本地选择一样进行优化，例如按索引排序以方便排序的流合并，但为什么不呢？