具有连接池的Select SQL的准备语句

Question

使用带有连接池的SELECT SQL的Prepared语句是一种好习惯。 （在我的例子中，我使用Tomcat JDBC连接池）。

它是否会增加任何优势（加速）或者它会增加维护准备语句，连接并使它们保持活动状态的开销，或跟踪是否在内部维护池化连接时关闭，并根据不同的设置关闭它们{{3} }。

我正在使用DataSource来获取连接，数据库是MariaDB。

在阅读各种as specified here时，posts和大多数Prepared Statement的示例都是使用INSERT或UPDATE查询构建的。是否指出SELECT它不会增加任何优势？

Answer 1

MariaDB / MySQL预处理语句在查询解析/优化方面没有任何优势，查询计划不像其他一些SQL数据库那样保留。

在传输结果集时，它们确实具有性能优势，因为列值可以以二进制形式传输并立即存储到结果变量中。使用经典的非预处理语句，所有结果字段都将在服务器端转换为文本形式。这增加了服务器端的处理时间，导致必须通过线路传输更多字节，并且根据您的应用程序需求，客户端可能需要将值从文本转换回二进制形式（例如，对于整数和浮点值）。

使用预准备语句的另一个原因，如前面的注释中所述，它是一种防止SQL注入的可靠方法，适用于SELECT以及INSERT / UPDATE / DELETE

Answer 2

如果可以的话，最好使用PreparedStatement：

• 防止SQLInjection
• 抽象日期/时间表示
• 处理Charset次转化
• 可读性（您看到一个包含完整SQL的字符串）
• 由于SQL保持不变（使用？），数据库可能会缓存计划而不必重新分析

在SELECT的情况下，原因主要在于传递到WHERE条件的参数。

至于表现：这可能取决于 - 但我从未经历PreparedStatement比简单Statement更糟糕 - 如果编码正确的原因。

您汇集连接的事实并没有增加太多。以某种方式“准备你将要在该连接上使用的所有语句以便以后”的概念不是如何使用PreparedStatments。一遍又一遍地准备相同的小语句是完全没问题的 - 如果面对INSERT或UPDATE的循环，重用PreparedStatement和/或批处理{{1}是明智的。 }}Š