第二：SQL的优化永远只针对大表之间的连接才用得上。不要怀疑，首先，我说的大表是指包含大表，不管是大表与大表，还是大表与小表
注：本文不是给你一个案例，而是讲调优的方法，古人云：授人鱼不如授人渔，这里要讲的，就是教你怎么捕鱼。
这里要说的sql调优很有意思，得先从感恩节说起。
感恩节（英语：Thanksgiving Day）是美国和加拿大共有的节日，由美国人民独创，原意是为了感谢上天赐予的好收成。11月的第四个星期四是感恩节。感恩节是美国人民独创的一个古老节日，也是美国人合家欢聚的节日，因此美国人提起感恩节总是备感亲切。感恩节是美国国定假日中最地道、最美国式的节日。
感恩节之后的第一天，是星期五，在这一天，美国人有疯狂购物的习惯，所以被称之为黑色星期五，近来己经由传统的商场购物改为网上购物，所以我的愕运便由此而生，我的DB便在这一天被疯狂购物给访问爆了。
客户提供了一份高峰时段的AWR报告，仔细分析后，发现竟然是一条高耗CPU的SQL给整跨了，仅仅一条，占了85%的CPU，这才深入去了解了SQL的优化，以前也做过DB的一些优化，基本上通过分析表、建索引、调参数、打PATCH等等都能解决，但这次，持续了一周，学了几天，还没解决。最终决定潜心研究SQL的优化，得出以下几点关于优化的结论：
第 一：1/9原则，引用Oracle大牛Tom大师的原话：数据库中90%的性能问题都可以由调整10%的SQL语句来解决。
Tom say: Sql tuning constitute a good 90 percent or more of the effort. Thats right; before we even get the DBAs involved, we the developers have done 90 percent of the work. This is why I think most people do not understand database tuning.
第二：SQL的优化永远只针对大表之间的连接才用得上。不要怀疑，，首先，我说的大表是指包含大表，不管是大表与大表，还是大表与小表，只要是有大表就行，因为小表与小表之间不会出现性能问题；其次：有连接才有优化的价值，我真的不知道单表的SQL有什么优化可言，对单表查询无非是三点：全表/索引/分区表，这三点，你肯定会。
第 三：说第三条之间，先说明：正如前面两条所言，数据库90%的优化在SQL，SQL的优化关键在“大表连接”，所以下面说的SQL优化都是指大表连接。
SQL的执行中，Oracle提供的执行计划，不是什么神秘的东西，其实就是oracle去表中查找我们所需结果的一个算法，算法这东西太熟了，在大学《数据结构》这门课中就学过（惭愧，这堂课从来都是去睡觉，因为当时根本不知道那位老朽在说什么），算法就是运算过程，在这里，就是指查找路径，说白了：执行计划＝算法＝查找路径，要找最优的执行计划，就是要找出最优算法，最优算法熟吧？ 不熟我跟你说几个名词："冒泡算法"，“折中算法”，“快速查找”，去过软件公司面试的人很多人肯定都做过这种题。而Oracle提供的执行计划中，恰恰就提供这些详细的过程在里面。你能看到Oracle先去哪个表/索引拿数据、根据什么条件拿多少行，再把拿到的结果去连接哪个表、等等，经过一系列的运算，最后得出什么结果给你。
但是，ORACLE也是一款软件，不是神，你给它一条SQL，它在开始运算之前，是不知道哪种算法是最优的，不可能每个都试一遍，再做比较吧，而且每条语句的执行计划上百种，每条语句都执行上百次，那服务器干脆别活了。所以，它只能预估一种针对这条SQL认为最优的算法，然后去执行。请注意：
1.永远没有最优算法，如果有最优算法a，那优化还需要做吗？每次都按最优算法a做行了。
2. Oracle认为最优的算法也不一定是最优算法，如果是的话，我们还需要做吗？
说到这里：我们就明白了，ORACLE调优的90%＝SQL调优＝大表连接调优＝执行计划调优＝算法调优，而大表连接就2点：1.连接顺序。2.连接算法（嵌套/哈希/合并）。
结论：SQL的调优就是手动设计出最优连接顺序和算法的执行计划。
