1

执行循环 SQL 查询的最佳实践是什么？我的理解是使用参数化查询并在第一次执行时将其转换为准备好的语句。如果这个查询需要多个线程执行怎么办？我需要为每个线程的每种类型的查询创建一个准备好的语句吗？还是如今 SQL 语句的解析如此高效以至于不再需要准备好的语句？

4

2 回答 2

2

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

大多数时候都鼓励使用参数化查询，不仅是为了性能，而且是为了防止 SQL 注入和防止数据类型转换问题（本地化日期时间）。

于 2009-08-04T19:31:08.847 回答
2

好问题 - 一次回答一点。

  • 执行循环 SQL 查询的最佳实践是什么？

如果除了参数差异之外查询将重复，则使用准备好的语句。

  • 我的理解是使用参数化查询并在第一次执行时将其转换为准备好的语句。

这就是我对应该做什么的看法。传统上，建议是在程序启动时准备所有查询。在我看来，这总是一派胡言。它使用查询使服务器超载，其中许多查询不会在任何给定的运行中使用，从而在客户端和 DBMS 中浪费内存。按需准备报表总是最明智的；当它第一次需要时，而不是除非需要。对于将“总是”执行的语句，我会允许例外——但我必须确信“总是”实际上接近 100% 的时间。

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

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

  • 还是如今 SQL 语句的解析如此高效以至于不再需要准备好的语句？

机器很快——是的。而对于不重复的语句，不值得担心开销。但是，如果您要执行几百万次查询，那么准备几百万次的成本就会开始增加。此外，数据库服务器机器通常是共享资源，但语句很可能为每个用户单独准备，因此如果您有多个用户通过重复查询被丢弃来锤击系统，服务器将忙于准备查询以执行任何他们很快。

所以，我的回答是“不”。当查询将被足够频繁地重复时，准备好的语句仍然是有益的——“经常足够”可能不是那么频繁。数百次 - 使用准备好的语句。数十次 - 可能使用准备好的语句。少于那个 - 也许不要使用准备好的语句。

于 2009-08-04T20:47:42.873 回答