一个programmer关于Oracle SQL的学习小结与思考

http://www.javaeye.com/topic/366991#
作为一个开发人员，开始认真系统学习
Oracle SQL也只有月余，之前的
SQL知
识仅仅是项目里面用到什么就去看什么，简单说就是
Read The Fxxking Guide。在系统学习
Oracle
SQL之前，俺的想法就是“按照需求完成功能，剩下的交给
DBA来处理”。这个想法从整体来看显而易见是错误
的，但若分割成两个独立的分句“按照需求完成功能”与“剩下的交给
DBA来处理”却又是正确的。接下来详细阐述我的观点。

 
你的问题是什么？

  
 这个问题应该无时无刻地回响在我们的脑海中。我们必须清晰地了解我们面对的问题是什么？否则就会演变成一句老话“进去的是垃圾，出来的还是垃圾！”。而
SQL调
优的最牛的境界就是不需要继续运行那个
SQL（因为无论如何调优，那条
SQL语句仍然会占用资源，
而不运行该
SQL，则它的
cost就是零，没有比这个更牛
X的了），要
做到这一步的前提，显然是充分理解所需处理的问题。不知道问题的来龙去脉，不知道写该
SQL的目的，或者是不清晰明白“我的问
题是什么”，写出来的
SQL的也是蹩脚
SQL，也是被无数
DBA深恶的
SQL，
也很可能成为应用的性能
murder。也是基于此原因，开发人员也应该熟练掌握基本
SQL语法，基本的调优原则，不要写出有明显性能问题的
SQL
语句。并且这是开发人员应该做的，且必须做到的，因为我们才是切实明白或者说更应该理解我们所需面对的问题的人,我们
才是对后续SQL调优的最佳人选
，而且
DBA
很难通过
SQL
语
句去了解开发人员写该
SQL
的目的，这一点就剥夺了
DBA
从
本质上提升性能的机会，留给他们的只能是无尽的猜测，
hint
，运气好的话，还能找到那个被诅咒的
开发人员问问写那条
SQL
的原因何在。当然，我由衷的希望这个
DBA
没
有带刀 ：）

  
 在明确了“问题是什么？”后，进一步就是按照正确的理解去实现
SQL。开发人员应该“按照需求完成功能”，不能完成功能的
SQL都
是垃圾，不论其性能多么优异，写得多么漂亮。就如，一条
SQL本该返回
100条数据，而实际却只返
回了
99条，那么哪怕是换一种写法能返回
100条数据，但是性能比目前的返回
99条
数据的
SQL要差很多，那么我们也应该选择能完成功能的
SQL，
99不
是
100，用户要的是
100，而不是