[if !supportLists]1、 [endif]问题现象描述
开户流程50用户并发情况，/mb/pj6vsv/visitor/sms-otp-verify-v2接口50并发响应时间超过6秒钟,应用服务器资源很低。
[if !supportLists]2、 [endif]问题定位过程
2．1、进入usercenter服务控制台，jps查看当前运行服务进程PID
[if !vml]
[endif]
2.2、先通过jdk自带的工具jstack保存一下JVM进程对应的栈信息，具体的命令是：
jstack -l 1> 1-stack，记录对应进行的PID，多记录几次线程堆栈的快照，方面后续在快照中找对应的线程调用内容。
[if !vml]
[endif]
2.3、查看生成的线程堆栈快照分析。查看到读取mysql相关的代码
截图待补充
2.4、考虑是数据的问题，进入数据库服务器查看资源情况。
[if !vml]
[endif]
数据库CPU使用率达到100%
2.5、查看数据库慢sql统计，其中updaate语句执行时间达到6秒或7秒钟。
[if !vml]
[endif]
2.6、分析sql语句。
UPDATEt_visitor SET status = N, gmt_modified =NOW(), modifier = creator WHERE is_deleted = N AND user_id = N
此sql语句执行计划扫描11w+数据记录，后续的where条件没有索引。
2.7、对比SIT发现此数据表存在user_id索引，所以在性能环境增加此索引。
[if !vml]
[endif]
2.7、增加索引后慢sql问题解决，响应时间从6秒钟降低到300+毫秒。但是数据库CPU使用率依然达到98%。
2.8、继续查看数据库慢sql，存在大量select语句的慢sql，分析此sql依然没有索引
SELECT
id,
user_id,
biz_type,
did,
mobile,
email,
user_name,
STATUS,
device_model,
device_sys_version,
country_code
FROM
t_visitor
WHERE
is_deleted = N
AND did = N
AND biz_type = N
AND STATUS = N;
2.9、对比sit数据库也没有对此sql进行添加索引，在性能环境考虑新增。
2．10、增加索引后结果如下。
性能测试环境对t_visitor数据表did字段增加索引后验证，数据库使用率从99%降至68.1%，TPS从最初14笔/秒，上升到74笔/秒。
[if !vml]
[endif]
[if !vml]
[endif]
[if !supportLists]3、 [endif]问题解决方案
3.1、如上步骤钟描述
[if !supportLists]4、 [endif]优化后结果
数据库使用率从99%降至68.1%，TPS从最初14笔/秒，上升到74笔/秒。
[if !vml]
[endif]
[if !vml]
[endif]
。
同时产生usercenter和corecenter服务CPU资源使用率过高问题，此问题的分析过程见文档：《使用jstack定位分析CPU消耗问题.doc》
