让人又爱又恨的笛卡尔_【四维研发Family】

笛卡尔，法国著名的哲学家、物理学家、数学家、神学家。“解析几何之父”,“现代哲学之父”,17世纪欧洲哲学界和...

笛卡尔，法国著名的哲学家、物理学家、数学家、神学家。“解析几何之父”,“现代哲学之父”,17世纪欧洲哲学界和科学界最有影响的巨匠之一，被誉为“近代科学的始祖”。这一连串的头衔你是不是已经不明觉厉了？如果你还不能体会到此人的魅力，那么我再进一步给您描述一下：百岁山矿泉水的广告都看过吧？但应该没几个人看懂了内在的含义吧，为什么一个开着豪车，带着皇冠，漂亮的不像话的公主，会提着长裙，花枝乱颤的跑去给坐在路边的一个流浪老头送矿泉水呢？

传说是这样的——笛卡尔在欧洲大陆爆发黑死病时流浪到瑞典，在斯德哥尔摩的街头，52岁的笛卡尔邂逅了18岁的瑞典公主克里斯汀，并成为了小公主的数学老师。小公主的数学在笛卡尔的悉心指导下突飞猛进，每天形影不离的相处使他们彼此产生爱慕之心，国王知道了后勃然大怒，将笛卡尔流放回法国。笛卡尔回法国后不久便染上重病，他日日给公主写信，在给克里斯汀寄出第十三封信后就气绝身亡了，这第十三封信内容只有短短的一个公式：r=a(1-sinθ）。

国王召集全城的数学家但没有一个人能解开，他不忍心看着心爱的女儿整日闷闷不乐，就把这封信交给了克里斯汀。公主看到后，立即明了恋人的意图，她马上着手把方程的图形画出来，看到图形，她开心极了，她知道恋人仍然爱着她，原来方程的图形是一颗心的形状。就是著名的“心形线”。

就是这样一个浪漫的法国老头，留下了一个很著名的乘积——笛卡尔积，在很多领域都发挥着巨大的作用，但独独在SQL的执行计划（oracle通过内部算法确定的消耗比较少的SQL语句执行路径就称之为执行计划。比如是先查数据还是先排序，是先做子查询还是先做主查询，用什么方式进行表之间的关联，走什么样的索引等等）中如果见到它（除非有意为之），心中一定是一紧！！！

笛卡尔积连接（执行计划中出现MERGE JOIN CARTESIAN字样，即用笛卡尔积的方式进行两表连接，简称笛卡尔积）是SQL执行效率的大敌，一言以蔽之——SQL语句执行慢并非都因为笛卡尔积，但执行计划中如果出现笛卡尔积，多数情况下会导致效率慢或者临时表空间不足。

就是由于这个笛卡尔积，我们的一个程序的运行时间竟然长达6天以上，不知执行这个程序的生产人员，每天早上瞅一眼还在执行中的程序，是怎样的心情？听，孩儿哭的声音……

执行计划中出现笛卡尔积，最常见的原因有两种：

第一种是多表A,B,C之间虽有传递的关联条件A.c1 = B.c1;B.c2 = C.c2，但因为oracle关联表是有顺序的，如果代码恰好写成了select * from A,C,Bwhere ……，则有可能在执行计划中出现笛卡尔积。那么这种情况的解决方法只需要改一下from 后面的表顺序，稳妥一点可以使用Hint把关联顺序固定下来，通常问题就解决了。

第二种则是多表关联，没有给出关联条件，那么执行计划中必出现笛卡尔积。它有多恐怖呢？举个例子，如果一个1000万数据量的表和一个100万数据量的表出现了笛卡尔积，那么会有10万亿条记录参与后续计算，计算机每秒处理1亿条，也需要10万秒，即一天的时间。如果一个程序中出现了6、7段类似的代码，那么执行6、7天也就算合理合法，并没有什么大惊小怪的了。看看下图执行计划中的耗费吧，是不是触目惊心？

两个没有关联条件的表就如同一个光棍男，一个待嫁女，素未谋面，没有共同语言，这时候需要什么呢？有人说是媒婆，有人说是非诚勿扰，好吧，都对！！其实他（她）们需要的是红线，是桥梁，消除笛卡尔积的关键就是给没有关联条件的表搭起一座桥梁，但事情通常未必那么简单，因为这个桥梁并不好搭，如前文列举的问题程序，代码中两个表之间确实没有可以直接进行关联的字段，这时候就需要变通了，需要技术之外的另一个帮手入场了——那就是业务，经过业务层面深入分析，A表的一个字段经过拆分后的某一部分，是可以作为与B表的关联条件的。于是对A表进行解析处理，专门生成一个“红娘表”C，前可连接A表，后可连接B表，再查看执行计划，笛卡尔积消失了，问题代码段的执行时间由1天骤降为3分钟左右，整体程序的执行时间缩短为20分钟，优化效果明显。