重复SQL查询

Question

执行重复SQL查询的最佳做法是什么？我的理解是使用参数化查询，并在第一次执行时将其变为准备好的语句。如果这个查询需要由多个线程执行，该怎么办？我需要为每个线程的每种查询类型创建一个准备好的语句吗？ 或者现在SQL语句的解析非常高效，现在已经不需要准备语句了？

Answer 1

好问题 - 一次回答一个问题。

• 什么是执行重复SQL查询的最佳实践？

如果查询将在参数差异之外重复，则使用预准备语句。

• 我的理解是使用参数化查询，并把它变成在第一次执行一个准备好的声明。

这是我对应该做什么的看法。通常，建议是在程序启动时准备所有查询。在我看来，这总是无稽之谈。它使用查询重载服务器，其中许多将不会用于任何给定的运行，浪费客户端和DBMS中的内存。按需编写报表总是最明智的;当它第一次需要时，而不是除非需要它。我会允许一个会“总是”执行的语句的例外 - 但我必须确信，“总是”真的接近100％的时间。

• 如果此查询需要由多个线程执行，该怎么办？我需要为每个线程的每种查询类型创建一个准备好的语句吗？

这取决于不同线程如何与DBMS进行通信。在我熟悉的DBMS中，如果线程共享一个单一连接，那么您只需为单个连接准备一次即可。如果每个线程都有自己的单独连接，则需要分别为每个线程准备语句。

• 或者是SQL语句时下非常高效，编制报表不再需要的解析？

机器速度很快 - 是的。对于不重复的陈述，不值得担心开销。但是，如果你要执行几百万次查询，那么准备几百万次的开销就会增加。另外，数据库服务器机器通常是共享资源，但是可能会为每个用户单独准备声明，因此如果您有多个用户使用重复查询丢弃系统，系统会忙于准备查询以执行任何操作他们的速度很快。

所以，我的答案是“不”。当查询经常重复时，准备好的陈述仍然有用 - “经常性”可能不是经常出现的情况。数百次 - 使用准备好的语句。几十次 - 可能使用准备好的语句。少于这一点 - 也许不要使用准备好的语句。

Answer 2

那么，你没有提到你正在使用的环境，但一般来说，你也可以考虑存储过程（如果你的数据库引擎支持它）。它具有在数据库本身中构建额外的抽象层的好处，从而使确切的数据库模式与客户端应用程序的关联性降低。

大多数情况下都鼓励使用参数化查询，这不仅是为了提高性能，还是为了防范SQL注入和防止数据类型转换问题（本地化日期时间）。