【发布时间】：2009-09-01 15:17:09
【问题描述】：
我已经阅读了很多关于准备好的陈述的内容，并且在我所阅读的所有内容中，没有人谈论使用它们的缺点。因此，我想知道是否有人们容易忽视的“有龙”的地方？
【问题讨论】：
-
IT 中的每件事都有缺点，您只需要检查它们是否真的值得在您的特定问题中担心。 :) SO stackoverflow.com/questions/535464/… 中的这个链接有一些关于准备好的语句缺点的例子。
【发布时间】：2009-09-01 15:17:09
【问题描述】：
Prepared 语句只是一个解析和预编译的SQL 语句，它只是等待提供绑定的变量被执行。
任何执行的语句迟早都会准备好（它需要被解析、优化、编译然后执行）。
准备好的语句只是重用解析、优化和编译的结果。
即使您自己不使用准备好的查询，数据库系统通常也会使用某种优化来节省查询准备时间。
Oracle，例如，在解析查询时首先检查库缓存，如果相同的语句已经被解析，则使用缓存的执行计划。
【讨论】：
-
我认为这个答案缺少准备好的语句的一个关键问题，例如。查询计划根据准备查询时存在的数据统计信息进行优化，并且在将来执行查询时可能不是最佳的。所以这是准备好的语句的缺点。
-
一些文章提到了类似的缺点：medium.com/@devinburnette/be-prepared-7768d1a111e1 --- 和 --- vividcortex.com/blog/2014/11/19/…
如果您只使用一次语句，或者如果您自动生成动态 sql 语句（并且正确地转义所有内容或确定您的参数只有 安全字符），那么您不应该使用准备好的语句.
【讨论】：
-
当然，这种情况极为罕见。我发现让服务器端准备好的语句内容进行输入清理要容易得多。
准备好的语句与动态 sql 相比还有另一个小问题，那就是调试它们可能更难。使用动态 sql，您始终可以将问题查询写入日志文件并直接在服务器上运行，就像您的程序看到的一样。使用准备好的语句，使用从崩溃数据确定的一组特定参数来测试您的查询可能需要更多的工作。但仅此而已，额外的安全性绝对可以证明成本是合理的。
【讨论】：
在某些情况下，数据库引擎在使用准备好的语句时可能会提出较差的查询计划（因为如果没有实际的搜索绑定值，它就无法做出正确的假设）。
参见例如
的“注释”部分http://www.postgresql.org/docs/current/static/sql-prepare.html
因此，可能值得在准备语句的情况下或不准备语句的情况下测试您的查询，以找出哪个更快。理想情况下，您将根据每个语句决定是否使用准备好的语句，尽管并非所有 ORM 都允许您这样做。
【讨论】：
-
我发现最好的模式是对准备好的语句使用全有或全无的方法。 DBMS 比我们大多数人都聪明，并且大多数时候都能找出最好的计划。此外，我确定您知道不同的 DBMS 将有不同的查询计划策略，因此不应将链接用作准备好的语句的全部内容。如果您将 DBMS 用于 Web 工作，防御 SQL 注入攻击的最快和最简单的方法是始终使用准备好的语句。
我能想到的唯一缺点是它们占用了服务器上的内存。这并不多，但可能有一些边缘情况会成为问题，但我很难想到任何问题。
【讨论】：