记录一次应用服务器、数据库服务器cpu、内存均正常的情况下，服务响应超慢的问题处理过程

周日早上八点半，微信群里实施经理：XX系统还没搞好吗，三天啦。。。

十一点半到早餐店点完餐，打开手机一块，未接来电*1，微信语音未接听，打开群消息一看，果然，负责两个项目的同事在群里一通排查，没查到问题，然后说让我给看下。

微信花了几分钟看了下聊天记录，发现没什么头绪，算了吧，等吃完饭到家再解决吧，然后给同事们发了个消息，让等我回去。

回到家，远程上服务器，实施经理反馈说之前正常，就最近不行了，问了下负责的同事最近都干了啥。同事说也没干啥，他们说卡，就把其中数据采集的服务部署到另外一个tomcat了，使用的nginx转发的，nginx是之前就有的，应该不会有什么问题。新部署的tomcat是8.5之前的是8.0。

难道是tomcat版本问题？复制了之前的tomcat，问题依然存在。查了下采集服务日志，发现很多超时的错误，问了下采集端那边的同事，发现是文件服务的代码，文件服务超时了，默认是60秒的超时时间。

试了试文件上传服务，2min，感觉不太对劲，为什么会这么慢呢？把nginx关掉，屏蔽掉现场的访问，发现时间降下来了，30秒，能正常访问了，但是也还是太长了。很费解，然后登录了显示端，查看列表1min。不对啊，这是刚调好的问题，怎么这么快就翻车了？看了下应用服务器和数据库服务器的cpu和内存，都很低，也没打满，还能是哪里出的问题呢。

突然回想起来之前给山西一个现场排查问题的时候，排查了很久发现是服务器的硬盘出问题了，io响应时间过长，难道这次也是硬盘io的问题？分别打开应用服务器和数据库服务器的磁盘io（windows通过任务管理器->性能->资源监视器->磁盘查看），果然数据库服务的磁盘使用率一直在100%。

找到问题了剩下的就是解决问题了，发现磁盘使用全在oracle 表空间文件读取上。想想难道是有大表查询的时候没加上索引，导致数据库全表查询把io打满了？查一下正在执行的sql

select a.username, a.sid,b.SQL_TEXT, b.SQL_FULLTEXT
  from v$session a, v$sqlarea b 
where a.sql_address = b.address 

排查完里面出现频率高的SQL，果然涉及到文件表、设备数据表、人员信息表这几张500W左右的数据表，均存在查询的部分字段没有索引，关闭应用，加上索引。刷卡正常，数据上传正常，遂交代项目负责人，后续其他功能遇到慢的时候也排查下索引问题，另外其他地区添加相同索引，别等数据量上来了再处理。

总结：随着系统的使用，用户数据量的增加，代码的不停迭代，容易产生一些经常使用并且数据量大的表缺失索引，最终拖慢整个系统，导致系统无法使用，所以索引这种东西在做查询的时候还是要好好设计下，如果主要的业务表容易被用作查询条件的字段最好还是都加上索引，避免以后因为索引的问题导致系统无法使用。