今天，想起之前在数据库上新上了一个schema，当时说负载可能比较大，正好有空了，所以，上去看看(应该有一些监控负载手段比较好)。
看了一下系统负载，确实高了一些，CPU比较繁忙，io等待有一些，但不多。
然后登陆db，查看当前当前的一些sql，发现新上的schema有十几个session都是同一条sql。
仔细看这条sql，很简单，却用了2个子查询。想要得到运行目前这条sql最后的结果，完全不用子查询，还有一个没有必要的全表排序。所以看了这条sql，我也不明白到底要查什么，才会这样写sql。这个目前这个表还不大，30M+，但CPU顶不住这样频繁的排序。
然后负载又升高了，基本上每个CPU达到90%，因为之前早一些的时候，应该还没到高峰时期。vmstat在running上堵了不少。这个时候登陆系统敲命令都能明显感觉到“一卡一卡”地。
后来看了下awr报表，基本就是这条sql的问题。
补充，后来询问得知写那条sql的老兄已经离职了，没有人再能解释为什么会这么写，sigh~~
遗留问题：
1 最好能想办法监控负载
2 sql的好坏会极大地影响db性能，db可以调整参数，但是从sql上着手，更本质一些。之前也经常遇到说速度慢之类的问题，基本就是sql太烂。一开始的表设计也很重要，目前我还没看过相关内容，先记下。
3 awr报表要系统的看一下说明。平时多看看awr。考虑每天自动生成awr。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/23650854/viewspace-682707/ ，如需转载，请注明出处，否则将追究法律责任。
