生产问题-某接口服务处理能力急剧下降问题原因定位分析

1 问题现象描述

项目上线的第二天，发现在早上10点后，随着时间的推移，运维反馈耗时一直在增长，且延迟增加的交易总笔数呈现明显的增长趋势。而前一天平均处理时间不到1秒，而那时交易的处理延时很多都开始超过2秒，且呈现增长趋势。

2 问题原因分析
首先通过SQL语句查询交易日志表，按时间（分钟）、交易笔数、平均交易耗时、最大交易耗时、0~0.5秒交易笔数、0.5~1秒交易笔数、1~2秒交易笔数、2~5秒交易笔数、大于5秒交易笔数等维度进行分析，获取处理延时的概要情况进行了解。
然后通过uptime命令检查各服务器负载情况来看，发现数据库服务器的负载呈现明显的增长趋势。

进一步获取数据库awr快照，从慢查询、非空闲等待事件、cpu、IO等消耗情况进行分析，主要发现某个SQL的cpu资源使用占比太高，

此SQL语句访问到的表是一张日志表，已有90多G，且查询条件对应的列A没有索引。因此怀疑问题发生的原因为此表部署时只是重命名后没加索引，通过生产环境和压测环境数据库索引约束对比。发现压测环境此日志表列A建了唯一性约束（注：创建唯一约束会在Oracle中创建一个Constraint，同时也会创建一个该约束对应的唯一索引），而生产环境日志表列A没有约束也没建索引。导致当此日志表数据量超过一定量时访问性能急剧下降。

对列A建唯一性约束后，数据库的负载降为正常，系统处理能力，处理能力恢复正常。

3 问题总结
后期将对此日志表只保留当天的数据，历史数据迁移到历史表便于后期的分析用