我是否应该总是更喜欢使用准备好的SQL语句来获得性能优势？

Question

我的理解是，预处理语句在服务器上编译一次，从而节省了重复解析，优化等的开销。显然，我应该总是更喜欢使用预处理语句来运行超过一次。

这种方法有任何缺点吗？

我正在使用从C ++到mysql的odbc（libodbc ++）。

Answer 1

Prepared Statements：

  

为什么要使用准备好的陈述？

     

使用有许多优点   你的准备好的陈述   安全和应用程序   表现原因。

     

准备好的陈述可以帮助增加   通过分离SQL逻辑来实现安全性   提供的数据。这个   逻辑和数据的分离可以提供帮助   防止一种非常常见的类型   漏洞称为SQL注入   攻击。通常在你交易时   使用即席查询，您需要   处理数据时非常小心   您从用户收到的。这个   需要使用逃避的函数   所有必要的麻烦   字符，例如单引号，   双引号和反斜杠   字符。这是不必要的   处理准备好的陈述。该   分离数据允许MySQL   自动考虑这些   字符，他们不需要   使用任何特殊功能逃脱。

     

表现增加   准备好的陈述可以来自   几个不同的功能。首先是   需要只解析一个查询   时间。当你最初准备的时候   声明，MySQL将解析   用于检查语法和设置的语句   要运行的查询。然后，如果你   多次执行查询，它会   不再有那个开销。这个   预解析可以带来速度   如果你需要运行相同的增加   查询很多次，比如在做什么时   许多INSERT语句。

     

（注意：虽然它不会发生   MySQL 4.1，未来的版本也将   缓存准备好的执行计划   陈述，消除了另一点   您目前为每个人支付的开销   查询执行。）

     

表现可能的第二个地方   增加是通过使用新的   准备的二进制协议   陈述可以使用。传统的   MySQL中的协议总是转换   发送前一切都变成了字符串   他们穿过网络。这意味着   客户端将数据转换为   字符串，通常大于   原始数据，通过它发送   网络（或其他运输）到   服务器，最终解码   字符串转换为正确的数据类型。该   二进制协议删除它   转换开销。所有类型都是   以原生二进制形式发送，其中   保存转换CPU使用率，和   也可以减少网络使用量。

     

什么时候应该使用准备好的陈述？准备好的陈述可以   对以上所有都有用   原因，但他们不应该（和   不能用于所有的东西   你的申请。首先，类型   他们所处理的查询是   限于DML（INSERT，REPLACE，   更新和删除），创建表，和   SELECT查询。支持额外的   查询类型将进一步添加   版本，做好准备   语句API更通用。

     

<强> - ＆GT;有时准备好的语句实际上可能比常规语句慢   查询即可。原因是这样的   有两个往返的往返   服务器，可以减慢简单   仅执行的查询   单次。在这种情况下，一个   必须决定是否值得交易   关闭这对性能的影响   额外的往返为了获得   使用准备的安全利益   语句。

Answer 2

几乎总是。

http://use-the-index-luke.com/sql/where-clause/bind-parameters

Answer 3

大量活动的预准备语句会占用额外的服务器内存。例如，它可能是嵌入式平台的问题（例如，IPhone上的sqlite数据库）。

Answer 4

您应该始终更喜欢使用准备好的语句来获取安全性的好处。它们几乎消除了SQL注入的漏洞，而您不必担心SQL转义值。

如果您的查询不经常运行（每个请求少于一次），则准备好的语句可能需要更长时间才能运行。它需要两次调用才能使用预准备语句：一次准备它，一次执行它。通过ad-hoc声明，这两个步骤一举完成，并且没有等待服务器说“好，完成编译”。

所有这一切的结果是，如果您担心性能，并且您的查询只运行一次，那么即席查询可能会更快一些。但安全性好处几乎总是超过准备声明所需的额外时间。