执行计划——DBA的恨，开发人员的伤

一直以来，DBA对开发人员指责最多的便是对执行计划的忽视。而开发人员对此的回击也很犀利：我只需要保证业务逻辑的正确执行，至于性能优化？那是DBA的事（DBA恨的牙痒痒~）。似乎这也成了很多开发人员的共识。

 

作为一个开发团队，DBA和开发人员是一个密不可分的整体。只有精诚合作，才能让系统更加健壮，更加稳定，性能更加出色。通常来说，DBA比开发人员更加了解数据库，并且知道数据库如何工作。当然，开发人员比DBA更加了解软件开发。似乎这正说明了二者的工作职责。只是，很多时候，作为一个团队，DBA和开发人员却各自埋头苦干，没有良好的沟通，这是前面提到的问题的症结所在，也是导致性能问题层出不穷的原因之一。

 

在现实生活中，很多公司（尤其是小软件作坊）都是这样，或者根本就不进行优化。去年我兼职的那家公司便是如此。糟糕的管理加上对技术的概念模糊，或者说领导对技术的不重视，造成了现场出现问题才来想办法解决，很多时候都是救急型的，根本就没有彻底地解决问题。如此往复，维修费用便居高不下，这是很大的一块开销。而且，测试环境和生产环境不可能完全一致，造成一些业务逻辑在测试环境下运行良好，而一到生产环境便出现性能问题，这样的问题屡见不鲜。当然，这是无法避免的，因为测试环境的数据量、硬件环境和生产环境的数据量、硬件环境不可能等同，所以只能尽量模拟生产环境，这就显得测试尤为重要。

 

说到性能测试，第一利器非执行计划莫属。像trace 10046事件、sql_trace参数、autotrace等，这些都能够获得执行计划。具体的方法可以参考很多书籍，或者百度谷歌一下，会有满意的答案的。在N多大牛出的书里面，都可以发现，几乎通篇都有执行计划的身影，有的甚至单独列出2到3章，详细介绍执行计划、如何读懂执行计划，由此可见执行计划的重要性。通过执行计划，我们可以从中得到表连接的执行顺序，物理读、逻辑读、递归查询次数等详细信息。通过这些，有经验的DBA会得到他想要的东西。这里推荐两本书（非广告~）：《Troubleshooting Oracle Performance》、《海量数据库解决方案》，这里面对各种执行计划都有详细描述，值得一读。或者可以参考Oracle的白皮书，E文的。对很多朋友来说，可能是个障碍。不过对于搞数据库的来说，不会E文真是个大麻烦。

 

 

 

PS：关于执行计划的详细内容，等有空的时候再写文章论述。