有一次遇到一个问题。当然这图已经被我涂抹的没法看了（还是涂抹掉没有风险）。但是依然能得出一些信息。（补充，该SQL根据报上来的情况是执行一次8秒以上）
1、10个表进行关联（一个个数下来）
2、where就一个id（看数量级是一个，应该属于点查）
3、省略了大量的列（列越多回表越大）
4、cost很大。(点查不应该这么多)
5、用到了dblink（有remote）
要优化，这个工作其实涉及的东西非常多。索引、统计信息、直方图、嵌套关系、SQL写法等等等，不了解数据库的可能不以为然。可能最终我们能很快解决，但是涉及的东西不得不一一确认，可能性太多了。当然处理这个算我运气好，只做了一个就好了。
就是上图这个的红框是左边的这个列缺索引。造成了该表的全表。那么先手工增加看看。效果显而易见。cost从86000多将到680左右，理论提升120多倍。实际反馈也是在80毫秒左右。速度提升也差不多是100多倍。理论和实际大体一致。
事情表面结束了，那么带来的思考有如下：
1、我一向反对dblink关联（所有要用物化视图或者ogg来解决跨库查询）但是上面是实在没办法的背景下，只能硬着头皮优化。这个背景是一个CDB之间的PDB跨库查询。实际看下来也还行。毕竟跨越N个PDB摆在那里，好在没有外部网络。PDB之间的dblink也不差。
2、不得不说Oracle强，一个PDB上的连接N个PDB，他的执行计划还很准。
3、我一向反对多表关联，不管在什么数据库上。这次是10表关联，我其实看到也有点发怵，不懂业务逻辑下，太难评价每个环节，对还是不对，好还是不好。但是Oracle这优化器，还是准确的搞定了。为什么说这个难？比如我们写select from a,b where a.id=b.id and a.id=1;数据库不知道ab是什么。通常会改写成select from a,b where a.id=b.id and a.id=1 and b=1;因为是等价的。至于先找a.id=1 还是 b=1看哪个优了。但是他有两个选择。如果三个表呢？他有6个组合选择。即3！3的阶乘。10个表呢就是10！，10的阶乘是多大，我算不过来。这在任何数据库中都是这样。
那么是不是所有数据库都能这样跨数据库，10表关联出这个效果？估计不是。
4、最终在不改SQL的场景下，提升了100倍多，全靠数据库自己的优化器和执行器完成。
5、有一次在一个PostgreSQL群中看到一位专业人士说到：说一个oracle极难被超越的地方，就是故障处理owi的思想。虽然国产很多也在借鉴，但是没有做的很好的。即使现在，一个好的dba就是it后台运维故障处理的入口，前台只会说交易慢了，清算慢了，Oracle dba可以甚至可以最终定位到存储光纤线光衰（硬件一点不报错情况）。
业内有的大咖说Oracle领先其他有代差，10-20年。从有些各种点滴场景来看，客观上来说，这些评价都不过分。
