执行重复SQL查询的最佳做法是什么？我的理解是使用参数化查询并在首次执行时将其转换为预准备语句。如果此查询需要由多个线程执行怎么办？我是否需要为每个线程的每种类型的查询创建一个准备好的语句？ 或者现在解析SQL语句如此高效，以至于不再需要预处理语句了吗？
答案 0 :(得分：2)
嗯，你没有提到你正在使用的环境，但一般来说，你也可以考虑存储过程（如果你的数据库引擎支持它）。它的好处是可以在数据库本身中构建一个额外的抽象层，从而使确切的数据库模式与客户端应用程序的相关性降低。
大多数情况下鼓励使用参数化查询，不仅是为了提高性能，还提供针对SQL注入的安全性以及防止数据类型转换问题（本地化日期时间）。
答案 1 :(得分：2)
好问题 - 一次回答一下。
- 执行重复SQL查询的最佳做法是什么？
如果除了参数的差异之外将重复查询，则使用预准备语句。
- 我的理解是使用参数化查询并在首次执行时将其转换为预准备语句。
这是我对应该做什么的看法。传统上，建议是在程序启动时准备所有查询。在我看来，这总是无稽之谈;它使用查询重载服务器，其中许多不会在任何给定的运行中使用，在客户端和DBMS中浪费内存。按需准备陈述总是最明智的;什么时候需要它，除非需要它。我会允许“永远”执行的陈述例外 - 但我必须确信“总是”真的接近100％的时间。
- 如果这个查询需要多个线程执行怎么办？我是否需要为每个线程的每种查询创建一个预准备语句？
这取决于不同线程如何与DBMS通信。在我熟悉的DBMS中，如果线程都共享一个连接，那么您只需要为单个连接准备一次。如果每个线程都有自己独立的连接，那么您需要分别为每个线程准备语句。
- 或者现在解析SQL语句如此高效，以至于不再需要准备语句了吗？
机器很快 - 是的。对于非重复的陈述，不值得担心开销。但是如果你要执行几百万次查询，那么准备它几百万次的成本就开始增加了。此外，数据库服务器计算机通常是共享资源，但该语句可能是为每个用户单独准备的，因此如果您有多个用户使用丢弃的重复查询来锤击系统，则服务器将忙于准备查询以执行任何他们很快。
所以，我的回答是“不”。当查询经常重复时，准备好的语句仍然是有益的 - 其中“经常足够”可能不是那么频繁。数百次 - 使用准备好的陈述。几十次 - 可能使用准备好的陈述。少于此 - 也许不要使用准备好的陈述。