【问题标题】:What are the bennefits of prepareThreshold = 5 in pgjdbc?pgjdbc 中 prepareThreshold = 5 的好处是什么?
【发布时间】:2019-10-09 05:06:39
【问题描述】:

pgjdbc 中的prepareThreshold 有如下定义:

在切换到使用服务器端准备好的语句之前,确定所需的 PreparedStatement 执行次数。默认值为五个,这意味着在第五次执行相同的 PreparedStatement 对象时开始使用服务器端准备好的语句。有关服务器端准备语句的更多信息,请参见“服务器准备语句”部分。

我想知道这实际上给我们带来了什么好处?大多数网络服务器几个月都不会重新启动,所以所有数据库查询最终都会发送超过 5 次,所以给它一周左右的时间,所有准备好的语句都将存储在服务器上,不是吗?这仅仅是为了使桌面应用程序受益吗?还是我错过了一些东西,例如“一段时间内的 5 个阈值”?

【问题讨论】:

  • 该设置是针对每个连接的,通常使用合理的连接池配置,单个连接将无法存活数月(甚至数小时)。而当不断发布新功能时,应用程序本身的运行时间可能是数小时或数天,而不是数月。
  • 我明白了...所以我认为的好处就是不会用不经常使用的准备好的语句使服务器膨胀,对吗?是不是这里有别的东西?

标签: postgresql jdbc prepared-statement pg-jdbc


【解决方案1】:

我了解到您想知道为什么 JDBC 驱动程序在使用服务器端准备好的语句之前要等待。

如果不参与决策过程,我会说原因是准备语句意味着一定的开销(发送准备、绑定和执行调用)。只有当您确信该语句将被重用时,这样做才有意义。

不要忘记,准备好的语句还有其他用途,可以在多次执行时节省 Parse 步骤:这是避免 SQL 注入的王道。仅此一项就证明了准备好的语句是合理的,即使它只执行一次。

【讨论】:

  • 是的,我主要用它来避免SQL注入。
  • 这不是我的问题的主题...但是如果 PostgreSQL 使用像 SHA1 这样的哈希来识别哪些准备好的语句已经在服务器上,我猜整个绑定过程会更顺畅(我只是在猜测,因为我不是这方面的专家,甚至没有接近)
  • 如果您阅读 PostgreSQL 中的预处理语句,您会发现它们总是有一个名称,这就是您在使用它时必须指定的名称。即使是“未命名的准备好的语句”也可以这样工作(名称是一个空字符串),不同之处在于您不必释放它。
  • 因此驱动程序可以创建一个名称为查询的 SHA1 的准备好的语句,然后绑定到服务器上已经存在的任何准备好的语句,另一个连接已经在过去创建...我想知道为什么他们不这样做,或者如果他们这样做..
  • 您的想法会降低性能。首先,每次都要将语句本身发送到服务器,如果SQL文本很长,这很浪费,那么服务器每次都必须计算哈希。如果客户说:“准备此语句并将其命名为 'foo'”,然后“现在使用这些参数执行 'foo',这会更好。为什么会打扰您?
猜你喜欢
  • 2019-10-09
  • 2022-01-11
  • 2010-12-11
  • 1970-01-01
  • 1970-01-01
  • 2021-08-17
  • 1970-01-01
  • 1970-01-01
  • 2019-06-15
相关资源
最近更新 更多