解决问题的一次历程

最近刚从一家人力资源公司离职，至一家医疗器械公司担任软件软件开发工作，目前主要工作基本以为不同医院开发并配合实施部署定制化平台，现将最近在公司遇到的问题和解决问题的思路做一次简单的整理，一是方便今后查漏补缺，二是与大家分享一下，交流交流意见!

项目的交互形式是：终端设备将实时监控数据数据传输到云服务器，然后医院的定制化系统再每隔10秒钟从云服务器拉取云服务其中未被前置机拉取过的数据，存放在医院的定制化数据库中。遇到的问题是：其中一家医院运行一段时间（大概一两天左右），经常出现有一到两个小时取不到数据，隔了一到两个小时，系统恢复正常。

   遇到这种问题，一般先排查网络层的原因，先查看log日志，发现问题时段一直报云数据库连接超时，我就从医院前置机（部署定制化的服务器）分别ping云服务器IP和百度首页IP地址,一天后对比发现ping云服务器与百度的数据相差不大，基本在30ms-50ms之间，平均40ms左右,没有丢包，但中间出了一个状况：ping云服务器的时候出现了最长连接168ms,所以网络问题既不能确定，也不能完全排除。

然后我又远程到医院前置机，隔段时间查看一次，终于找到了问题时段，立马telnet云服务器数据库端口，发现端口是通的，所以网络问题算是排除掉了！

那么问题只能出现在程序和数据库了，于是我登录到数据库，发现有时能登陆，有时登录不上，但是逻辑又说不通，因为医院的前置机是在一段时间内一直连接不上，所以暂时先以这个方式解决：增大数据库连接超时时长，同时排查其它问题。

增大数据库连接超时时长后发现问题出现的比之前更加频繁，由原来的一两天出现一次加速为几个小时出现了一次，所以这个方向也是错误的，在这个过程中我注意到，虽然打印的是数据库连接超时，但报错的显示行号并没有在数据库连接所在行，而是在sql查询所在行，所以问题很有可能是出现在sql上。

于是，我将程序中的sql复制出来，单独在客户端查询，终于找到问题所在：查询几次反应时长基本在40s左右，最长的一次竟然用了61s。

于是便分析出原因，由于云服务器存放的是所有医院监控数据，日积月累数据量越来越大，所以导致查询效率越来越低，解决的方案就是为表对应的查询条件所在列建立联合索引，至此问题解决！