Performance 有人能提供一个场景，其中准备好的声明有利于提高效率吗？

不用于sql注入保护。我知道这一好处，但就编译的部分和它更高效而言，我找不到一个可以提高效率的场景。我希望在这里。我知道，但除了这里，我不知道去哪里问。谢谢。

人们可以很容易地列出准备好的陈述的好处

您可以消除编译开销

你不再需要准备执行计划

由于不是语句，而是只有参数需要通过导线传输，所以可以获得带宽

如果您有一个语句在很长的时间跨度内工作数百万次，那么所有这些项对于效率都很重要。如果它很容易开发（像存储过程），那么这是一个双赢的局面，但是

我曾经不得不开发一个代码，使用“嵌入SQL的C”直接连接到AS/400系统，您在C代码中编写SQL，将其交给预处理器以输出可编译代码和绑定文件，然后将绑定文件交给AS/400系统以准备语句。这一切都是因为他们拒绝在服务器上安装ODBC支持

编写和测试代码是一件痛苦的事情。它工作得非常慢，任何改变都肯定会破坏系统。写这样的代码是不高效的

效率取决于变量，而变量因您的观点而异

在我的样本中，AS/400的人很高兴，因为他们通过不在系统上安装一些cr.p软件来保持系统的效率。客户很高兴，因为他们强迫开发人员使用低效的方法来编写代码的方法是高效的，足以将其保持在时间表中。这对于网络管理员来说是非常有效的，因为网络上传输的数据很少（甚至没有元数据）。对于开发人员来说，这是非常低效的，因为它既耗时又容易出错。但是对于同一个开发者来说，在简历上写些“好看”的东西也是非常有效的

---

您现在看到了吗？

场景很简单：事务处理

正如Edokan所说，准备语句消除了编译SQL和创建执行计划的开销。在更复杂的查询中，这种开销是最小的。但是，如果每秒运行100或1000个事务，则此开销可能会影响数据库的有效使用

当然，查询计划可能不是最好的，尤其是当底层表的统计信息发生变化时。准备时的特征用于确定最佳查询计划。这些可能会随着时间的推移而改变，不同的查询计划可能会变得更好。对于更复杂的查询来说，这是一个更大的问题。由于这些通常需要更长的时间来运行，因此编译开销不是什么问题