【开端】
由于最近Oracle数据硬盘空间严重不足，表空间无法扩展，再加上接口访问量巨大，归档日志时不时就过满，导致有一整个下午系统宕机，无法使用。
于是我们叫来了添加Oracle硬盘的数据库管理人员，摸鱼了几个小时，都在等待硬盘加好。
硬盘加好后，重启数据库，一切看起来都十分正常。但是同事突然发现有的时候网页会严重卡顿，接口请求超时，页面上没有任何的数据出现。
wtf???!!!这可是严重的事情呀！
由于新加了Oracle硬盘，再加上这段时间，经常由于归档日志导致的服务异常，因此我们将大量的精力放在了我们不熟悉的运维上，查询数据库连接数，查询服务器连接数，查询服务器性能，查询归档日志量，排查了很久很久，但是依旧没有任何结果，大概到了十一点多的时候，重启了第N次服务后，终于好像迎来了一段时间的寂静，好像没有那么的卡顿了？
是某种我们不知道的力量帮助了我们吗？？？
但是不管怎么样，已经太晚了，我们就安心离开了。
【中场】
但是第二天来公司上班，又又又卡顿了！！而且卡顿的更严重了！！这是什么玄学的力量在陷害我们吗？？
算了，埋头又排查了段时间后，突然觉得会不会是我们把问题想复杂了？
于是，我将日志输出级别更改至debbger级别，终于，发现了每次严重卡顿的时候都会有执行一条sql，这条sql捞出来放在Oracle执行大概会有30至40秒的执行时间，原来是这条sql导致的整个系统的卡顿！！
【结尾】
好吧，那就两种方案，一个就是优化，另一个就是弃用。
优化无非就是加索引之类的优化，也做不了分库分表。
由于我们之前改造过程序，而那条导致卡顿的sql是以后的祖传sql，所以我们最后选择了弃用，最后程序又能很流畅的跑起来。
最后得到的教训就是要从简单排查到复杂，不要忽视代码和sql。
