Java H2语句池

使用准备好的报表的原因有两个：

通过仅将来自外部世界的数据添加为参数来防止SQL注入

通过让DB预先解析语句一次并通过传递参数多次重复使用语句来提高性能

但是JDBC中准备好的语句与连接绑定在一起。我们应该使用连接池。这意味着在典型的代码示例中，我必须

• 从池中获取连接
• （重新）-每次都要创建准备好的语句，因为没有其他合理的方法将其取回

---

使用H2附带的简单连接池JdbcConnectionPool时，我认为语句不会被缓存。这是否意味着在使用准备好的语句时会对性能产生相当负面的影响？由于上面（1）的原因，我无法真正避免这一点。

H2在连接级别上透明地缓存准备好的语句。也就是说，只要在创建准备好的语句时SQL字符串相同，并且使用相同的连接，它就不会被重新解析，而只是作为缓存查找的不透明字符串进行比较（请参见

org.h2.jdbc.JdbcConnection#prepareCommand（…）

）

您可以使用参数

query\u cache\u size

-更多信息配置查询缓存大小

根据您的使用场景，您可能希望尝试根本不使用连接池。例如，作为嵌入式数据库，连接成本并不高。如果只使用一个连接，您可能会获得更大的性能提升（缓存命中率更高；内存消耗更低，因为您不会复制缓存）。此外，H2的许多部分（AFAIK）并不是真正为并发而构建的

所以要回答你的问题：

不，我不认为这本身对准备好的语句的性能有负面影响。恰恰相反

---

然而，想想你想使用哪种类型的游泳池，以及你希望它有多大。另外，您期望什么样的并发性？然后测量您希望在实时应用程序中看到的场景中的速度和内存消耗。而且。。。想想这对您的应用程序有多重要。我怀疑其他地方可能还有更重要的事情要做。

“我认为语句没有被缓存”-你为什么这么认为？

%grep-I statement src/java/biz/source\u code/miniconpoolmanager/miniconpoolmanager.java

没有结果。啊哈，在

Session.prepareLocal（）

中找到了它。谢谢你的指点。至于真正的性能差异，这并不是一个真正的问题。我只是想完全理解它的影响，以防我在一个项目中遇到它。关于池：我刚刚读到H2连接是同步的，所以一个连接就足够了。但是为了与一般的JDBC契约保持兼容，我宁愿使用池。