很多系统上线后, 性能问题开发就基本上不管了 , 业务越来越慢的责任都压在DBA身上,而大部分DBA对SQL优化没有深入的研究, 就只能把希望寄托在硬件的改善上....最近遇到很多业务越来越慢的案例,都是SQL写法导致的问题,实现相同的业务逻辑, SQL写法不同, 性能相差几倍到几千倍,消耗的硬件资源也相差甚远....数据量小的时候差别不大, 数据量大了, 差别越来越大, 直到慢慢耗光你的硬件资源.
最近帮某个银行客户分析了两套oracle数据库, 客户反映说是系统慢, 迁移到了新的硬件平台,还是慢....获取的sql monitor执行计划如下, 执行时间一小时以上,其中一个大分区表(610个分区)的全表扫描消耗占了绝大部分:
SQL代码如下:
问题的关键在于最后一个红框的写法,EP2EAS_ITGOPENACCOUNT_HIST...这种SQL写法导致的性能问题, 靠补强硬件是没有意义的, 而且一开始系统上线的时候影响还不太明显(分区数少), 随着时间的推移, 分区数越来越大, 效率就越来越差.