Postgresql pgjdbc中prepareThreshold=5的作用是什么？

pgjdbc中的

prepareThreshold

具有以下定义：

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

---

我想知道这到底给我们带来了什么好处？大多数Web服务器在几个月内都不会重新启动，所以所有数据库查询最终都会发送5次以上，所以给它一周左右的时间，所有准备好的语句都会存储在服务器上，不是吗？这只是为了让桌面应用程序受益吗？或者我遗漏了什么，比如“一段时间内的5个阈值”

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

在不参与决策过程的情况下，我认为原因是准备语句意味着一定的开销（发送Prepare、Bind和Execute调用）。只有当您确信该语句将被重用时，这样做才有意义

---

不要忘记，在多次执行时保存解析步骤的预处理语句还有其他用途：这是避免SQL注入的最佳方法。仅此一点就足以证明准备好的语句是正确的，即使它只执行一次。

该设置是针对每个连接的，并且通常在连接池配置正常的情况下，单个连接不会持续数月（甚至可能不会持续数小时）。当不断发布新功能时，应用程序本身的运行时间可能是数小时或数天，而不是数月。我明白了……所以我认为这样做的好处就是不会用不经常使用的准备好的语句使服务器膨胀，对吗？这里还有什么吗？是的，我使用它主要是为了避免SQL注入。这不是我问题的主题。。。但是如果PostgreSQL使用类似SHA1的散列来识别服务器上已经准备好的语句，那么整个绑定过程将更加顺利（我只是猜测，因为我不是这方面的专家，甚至不是很熟悉），如果你仔细阅读PostgreSQL中准备好的语句，你会发现它们总是有一个名称，这就是你想要使用它时必须指定的内容。即使是“未命名的预处理语句”也是这样工作的（名称是空字符串），区别在于您不必取消分配它。因此，驱动程序可以创建一个名为查询SHA1的预处理语句，然后绑定到服务器上已经存在的任何预处理语句，即过去创建的另一个连接。。。我想知道他们为什么不这样做，或者如果他们这样做了……你的想法会降低性能。首先，每次都必须将语句本身发送到服务器，如果SQL文本很长，这是浪费，那么服务器每次都必须计算哈希。如果客户说：“准备这个语句并将其命名为‘foo’”，然后说“现在用这些参数执行‘foo’，那会更好。为什么这会困扰您呢？”？