Postgresql的CURSOR SHARING

Oracle DBA 最怕遇到 C URSOR 相关的问题，如果发生了 C URSOR 争用导致的性能问题，是很难在短时间内分析清楚的。有时候我们重启数据库就解决了这个问题，不过有时候重启数据库后问题依然存在。幸运的是在 PostgreSQL数据库中好像很少会遇到类似的问题，这是什么原因呢？ 在一个高并发的系统中， S QL 执行过程需要对 S QL 进行编译，这个过程无论哪种数据库都是必须有的。大体上分为语法语义解析、 SQL REWRITE 优化、执行计划生成、执行计划选择、执行等过程。在 PostgreSQL中，可以用下面这个图来表示。   为了避免每次 S QL 执行之前都做上述昂贵的操作， Oracle构建了全局共享的C URSOR 结构，用于在共享内存（ S HARED POOL ）中存储 C URSOR 共享部分的数据，用于所有的会话共享。似乎现在的 Mysql、PostgreSQL等开源数据库和一些国产数据库都没有再采用这种全局共享C URSOR 的机制，而大多数采用 S QL 不共享或者会话内共享 C URSOR 的机制，比如比较新版本的 PostgreS QL 就是采用会话内共享 S QL 的机制。 为什么 Oracle使用全局C URSOR 共享机制而 PostgreSQL不使用呢？这实际上有两方面的原因，一个是历史原因，一个是商业原因。 CURSOR 共享在 C PU 资源不是很充裕的时代是相当有效提升 R DBMS 执行效率的手段，因为 S QL 解析是十分高开销的工作，能够一次编译多次执行，可以大大提高系统的并发执行性能。因此作为商用数据库的 Oracle一直把提升C URSOR 共享能力作为其核心竞争力， O RACLE 的 C URSOR 全局共享就做成了一个独步天下的技术了。 Postgresql这样的开源数据库没有Oracle的大手笔，因此选择了较为稳妥的会话内共享S QL 的技术路线。幸亏是现在 X 86 服务器技术的高速发展， C PU 资源已经不是很难买到的了，因此不能在全局共享 C URSOR 的问题也已经不是一个特别严重的问题了。实际上，这些年我们遇到的因为 C USOR 硬解析导致的 O RACLE 数据库性能问题也少了很多，主要原因是哪怕 C URSOR 解析使用了 10+%的C PU 资源，对我们的服务器来说也还是撑得住的。 虽然说 P G 并没有采用全局共享 C URSOR 的策略，不过在会话内共享多次执行的 C URSOR 仍然对 P G 数据库并发执行性能的提升有极大帮助的。说起共享 CURSOR 就不可避免地会聊到绑定变量的使用问题。使用绑定变量的好处是让 SQL 可以共享，可以让一条类似的 S QL 在多次执行中 共享查询执行计划，这样就不需要每次都编译 SQL语句 ；不过使用绑定变了也有缺点，在 Oracle存在的b ind peeking 问题在任何数据库中都会存在，因为绑定变量的差异可能选择不同执行计划才好的问题在很多时候都是存在的。在 Oracle   9 iR2 之前，所有执行计划都是在变量绑定之前完成的，从 9.2开始, Oracle 将执行计划的生成放到了变量绑定之后，这样就让执行计划的生成更为精准了，不过这也带来了另外一个问题，那就是 S QL 第一次执行时的变量成为生成执行计划的依据，因此 C URSOR 共享会导致存在多种最优执行计划的 S QL 语句的运行性能变得不稳定。 Oracle   11 g 之后的自适应 CURSOR 共享才基本上解决了这个问题。 PostgreSQL数据库的C URSOR 共享机制学习了 Oracle的这一个新的特性，采用了一种类似的方法来解决这个即共享C URSOR 又尽可能避免多种最优执行计划导致的 S QL 性能问题，当然前提是， PostgreSQL的C URSOR 共享是会话级的，不是实例级的。 在 PostgreSQL的一个会话中，一条S QL 的前五次执行，每次都会重新生成执行计划，这样就可以避免因为绑定变量的差异导致存在多种最优执行计划的问题无法被发现的问题出现。如果前五次编译发现存在通用执行计划，那么这个通用执行计划就会被共享。我们来看下面的例子。   我们可以看到，在前面五次执行的时候 o bject_id 都是代入具体得值的，而第六次执行就变成 $ 1 ，这就是使用了通用执行计划。我们再来看一个复杂一些的例子。   从这个例子上可以看到，如果绑定变量出现了较大的差异，那么 Postgre SQL 不会一味的用通用执行计划去套用，而是会使用 c ustom 执行计划，通过全表扫描来替代索引扫描，从而确保 S QL 的高效执行，这和 Oracle的Adaptive   Cursor   sharing的思路基本上是一致的。