6

我调查了很多地方，听到了很多可疑的说法，从PreparedStatement应该优先于Statement任何地方，即使只是为了性能优势；一直声称PreparedStatements 应该专门用于批处理语句而不是其他任何东西。

然而，我所关注的（主要是在线）讨论似乎存在盲点。让我介绍一个具体的场景。

我们有一个带有数据库连接池的 EDA 设计的应用程序。事件来了，有些需要坚持，有些则不需要。有些是人为生成的（例如，每 X 分钟更新/重置一次）。一些事件来并按顺序处理，但其他类型的事件（也需要持久性）可以（并且将）同时处理。

除了那些人为生成的事件之外，在需要持久性的事件如何到达方面没有任何结构。

这个应用程序是很久以前（大约 2005 年）设计的，并且支持多个 DBMS。典型的事件处理程序（需要持久性）：

  • 从池中获取连接
  • 准备sql语句
  • 执行准备好的语句
  • 处理结果集，如果适用，关闭它
  • 关闭准备好的语句
  • 如有必要，准备不同的声明并以相同的方式处理
  • 将连接返回到池

如果一个事件需要批处理，则语句准备一次并使用addBatch/executeBatch方法。这是一个明显的性能优势，这些情况与这个问题无关。

最近，我收到一个意见，即准备（解析）语句、执行一次并关闭的整个想法本质上是对PreparedStatement. （Oracle、DB2、MSSQL、MySQL、Derby 等）甚至不会将这样的语句提升到预准备语句缓存（或者至少，它们的默认 JDBC 驱动程序/数据源不会）。

此外，我必须在 MySQL 的开发环境中测试某些场景，Connector/J 使用分析器似乎同意这个想法。对于所有非批量准备好的语句，调用close()打印：

PreparedStatement created, but used 1 or fewer times. It is more efficient to prepare statements once, and re-use them many times

由于前面概述的应用程序设计选择，拥有一个PreparedStatement实例缓存来保存连接池中每个连接的任何事件使用的每条 SQL 语句，这听起来像是一个糟糕的选择。

有人可以进一步详细说明吗？“准备 - 执行（一次） - 关闭”的逻辑是否存在缺陷并且基本上不鼓励？

PS 在为每个非批处理 SQL 语句调用实例时，为 Connector/J 显式指定and并使用其中useUsageAdvisor=true之一cachePrepStmts=true或useServerPrepStmts=true仍然useServerPrepStmts=false会导致有关效率的警告。close()PreparedStatement

4

5 回答 5

3

准备-执行[一次]-关闭的逻辑是否存在缺陷并且基本上不鼓励？

我不认为这是一个问题，本身。给定的 SQL 语句需要在某个时候“准备”，无论是显式（使用 PreparedStatement）还是“即时”（使用 Statement）。如果我们对只执行一次的事情使用 PreparedStatement 而不是 Statement 可能会产生更多的开销，但所涉及的开销不太可能很大，特别是如果您引用的语句是真的：

典型的 DBMS（Oracle、DB2、MSSQL、MySQL、Derby 等）甚至不会将这样的语句提升为预准备语句缓存（或者至少，它们的默认 JDBC 驱动程序/数据源不会）。

不鼓励的是这样的模式：

for (int thing : thingList) {
    PreparedStatement ps = conn.prepareStatement(" {some constant SQL statement} ");
    ps.setInt(1, thing);
    ps.executeUpdate();
    ps.close();
}

因为 PreparedStatement 只使用一次，并且一遍又一遍地准备相同的 SQL 语句。（尽管如果确实缓存了 SQL 语句及其执行计划，那么这可能也没什么大不了的。）更好的方法是

PreparedStatement ps = conn.prepareStatement(" {some constant SQL statement} ");
for (int thing : thingList) {
    ps.setInt(1, thing);
    ps.executeUpdate();
}
ps.close();

...甚至更好，通过“尝试资源”...

try (PreparedStatement ps = conn.prepareStatement(" {some constant SQL statement} ")) {
    for (int thing : thingList) {
        ps.setInt(1, thing);
        ps.executeUpdate();
    }
}

请注意，即使不使用批处理也是如此。SQL 语句仍然只准备一次并使用多次。

于 2015-10-11T14:49:40.797 回答
2

正如其他人已经说过的，最昂贵的部分是解析数据库中的语句。如果语句已经在共享池中解析，一些数据库系统（这几乎取决于数据库——我将主要针对Oracle发言）可能会受益。（在 Oracle 术语中，这称为软解析，它比硬解析便宜- 对新语句的解析）。即使您只使用一次准备好的语句，您也可以从软解析中受益。

所以重要的任务是给数据库一个重用语句的机会。一个典型的反例是在 Hibernate 中基于集合处理 IN 列表。你以这样的陈述结束

 .. FROM T WHERE X in (?,?,?,  … length based on the size of the collection,?,? ,?,?)

如果集合的大小不同，则不能重用此语句。

了解由正在运行的应用程序生成的 SQL 查询范围的一个很好的起点是（由 Oracle 提供的）V$SQL视图。使用您的连接池用户过滤 PARSING_SCHEMA_NAME 并检查 SQL_TEXT 和 EXECUTIONS 计数。

应避免两种极端情况：

  • 在查询文本中传递参数（ID）（这是众所周知的）和
  • 不同访问路径的重用语句。

后者的一个示例是使用提供的参数执行对表的有限部分的索引访问的查询，而没有参数则应处理所有记录（全表扫描）。在这种情况下，创建两个不同的语句绝对没有问题（因为对两者的解析会导致不同的执行计划）。

于 2015-10-11T15:59:01.300 回答
1

PreparedStatements更可取，因为无论您是否以编程方式创建一个，都需要一个；每次运行查询时，数据库都会在内部创建一个 - 以编程方式创建一个只是为您提供处理。PreparedStatement每次创建和丢弃 a并不会比使用 增加太多开销Statement。

数据库需要大量工作来创建一个（语法检查、解析、权限检查、优化、访问策略等）。重用一个绕过了后续执行的这项工作。

与其扔掉它们，不如尝试以可以重用的方式编写查询，例如忽略空输入参数：

where someCol = coalesce(?, someCol)

所以如果将参数设置为null（即“未指定），则条件成功）

或者，如果您绝对必须每次都构建查询，请在构建查询是关键PreparedStatements的地方保留对 的引用，并在遇到问题时重用它们。Map为您使用WeakHashMap<String, PreparedStatements>映射实现以防止内存不足。

于 2015-10-11T14:48:42.980 回答
0

就性能而言，只运行一次的 SQL 命令只会浪费在 Prepared Statement 中发送的数据库资源（内存、处理）。另一方面，不使用 Prepared Statement 会让应用程序容易受到 SQL 注入的攻击。

安全性（防止 SQL 注入）是否会影响性能（只运行一次的准备语句）？对，但是...

但它不应该是那样的。这是一个选择 java 没有实现让开发人员调用正确的数据库 API 的接口：只运行一次的 SQL 命令并得到适当的保护以防止 SQL 注入！为什么 Java 没有为这个特定任务实现正确的工具？

可能如下：

  • Statement Interface- 可以提交不同的 SQL 命令。一次执行 SQL 命令。不允许绑定变量。
  • PreparedStatement Interface- 可以提交一个 SQL 命令。多次执行 SQL 命令。允许绑定变量。
  • （在 JAVA 中缺失！） RunOnceStatement- 可以提交一个 SQL 命令。一次执行 SQL 命令。允许绑定变量。

例如，可以在 Postgres 中调用正确的例程 (API)，通过驱动程序映射到：
- Statement Interface- call PQExec()
- PreparedStatement Interface- call PQPrepare() / PQExecPrepare() / ...
- (MISSING IN JAVA!) RunOnceStatement Interface- callPQExecParams()

在只运行一次的 SQL 代码中使用准备好的语句是一个很大的性能问题：在数据库中进行更多处理，浪费数据库内存，通过维护以后不会调用的计划。缓存计划变得如此拥挤，以至于可以从缓存中删除多次执行的实际 SQL 命令。

但是Java没有实现正确的接口，强制大家Prepared Statement到处使用，只是为了防止SQL注入……

于 2020-05-27T16:08:33.057 回答
0

PreparedStatement 已创建，但使用了 1 次或更少。一次准备语句，多次重复使用，效率更高

我觉得你可以放心地忽略这个警告，它类似于声称每周工作前 40 小时比接下来 56 小时睡觉、7 小时后吃饭、剩下的时间是你的 空闲时间更有效率。

每个事件您只需要执行一次 - 您应该执行 50 次以获得更好的平均值吗？

于 2015-10-11T16:23:22.123 回答