哲人说：“你用了N久的时间去准备一件事，但真正做的时候，很快就做完了”。
所以，“过程，大于结果。所谓人生，要重视过程，……“
“Stop！！！”
人生的话题太厚重，不是我这个Level能聊的，咱还是继续聊IT吧，看一条SQL：
上面这条简单的SQL，Planning时间，是1.563ms，执行时间，是0.335。
Planning时间是SQL执行时间的4.6倍。
MySQL也有类似的问题，花在Plan上面的时间，比真正执行SQL要长的多。
从这一点上来说，PG/MySQL，和人生中好多事有曲异同工之妙啊。
做为千万富翁，拉里应该也发现了这个人生真谛。但，不是都说，拉里和上帝的区别，是上帝不认为自己是对方。
准备时间远大于做事情的时间，自认为是上帝的拉里，怎么可能对人生的这一BUG置之不理。
先上个图，看看拉里解决的结果：
图中parse time elapsed，就对应PG中的Planning Time。上图的统计结果显示，在Oracle中Planning Time只占总时间的0.22%，不足百分之一。
对比下PG中的4.6倍，460%，Oracle这个不足百分之一，真的解决了“准备时间远大于执行时间“，这一人生难题。
但是，这个结果是来自于Oracle自己的统计结果，会不会有什么问题？
我们换个角度统计下，从“指令“数角度，对比下Oracle与PG执行同样SQL时，所用指令数的不同。
SQL还是上面的SQL：select * from vage2 where id1=1
这是Oracle的结果：
这是PG执行同样的SQL，所用的指令数：
在同样的主机上，都是走主键索引的查询，表大小同样是300万行，结果集也都是1行，PG使用了237,124条指令，完成了和Oracle 99,839条指令同样的效果。
PG是Oracle的2.37倍。差别来自哪里？
Oracle解决了Planning Time阶段，耗用CPU过高的问题。相当于Oracle没有了复杂、耗时的Planning Time阶段，所用指令数大大减少，SQL执行时间也大大加快。
Oracle是怎么做到的？
很简单，Oracle把为SQL生成的Plan，存入一块内存。下次再执行同样的SQL，从这块内存中取出Plan即可，不再有“生成“Plan这个动作。
这块内存，就是共享池。
这就和上一篇《卡脖子的数据库：从一项功能说起》，连上了。还没看过的朋友，点此查看
https://mp.weixin.qq.com/s/OsgRuKs-1HtEpxbjOPx2aw
在上一篇文章中，对共享池有这样的评价：“自这个功能而始，将Oracle于其他数据库划分开来。“
这好像有点过了吧，怎么看，共享池都不过是增加性能的一个小把戏而已。
但历史往往如此，一些平凡的小人物，偶然间被推向浪花之巅，甚至决定着历史车轮的走向，……。
而且共享池可不是小人物，它的复杂度很高，是Oracle中唯二重要的内存池（另一个是Buffer Cache）。它是在怎样的姻缘际会之下，成为卡脖子的咽喉呢？这还要从优化器说起。
下集中，且听我细细道来。
