接口超时问题的排查思路和解决方案

业务场景：查询用户工作流程的任务列表接口超时。

在工作流程管理页面我们可以绘制工作流程，并指派任务给对应的用户，用户可以在自己的登录账户查看指派给自己的任务列表。

排查用户超时的思路

前提：首先我们这接口是限制最大返回30条，所以排除了是前端查询数据条数过多导致超时

1.确保服务部署没有问题、自己的网络没有问题

2.查看sql的执行时间，是否是慢sql，如果sql执行时间过长，那么就查看一下sql的执行计划，是否是全表扫描？是否有索引？

　　查看sql的执行计划：EXPLAIN  SELECT FROM xxx wherer ID = XXX

　　执行计划展示

 

 　　如果type=all那代表的是全表扫描，如果数据量大的话，查询耗时就会变长，此时应考虑加索引。

　　 有些时候我们加了索引查询还是很缓慢，此时可以考虑加缓存，建议(coffeine+redis)

　　 加了索引查询很慢的原因有很多比如使用索引条件查询匹配到很多数据，主索引树需要依次回表获取结果集、内存不足、网络速度慢、锁或死锁

　3.统计你认为出现可能出现超时的代码段运行时间，定位超时的代码片段，对代码进行优化

总结

在我这次遇到的接口超时的问题，经排查后发现camunda内置的任务变量查询接口sql是全表查询的，且我们是循环的去获取任务对应的任务变量，由此就导致的接口超时。

解决方案

根据sql的查询条件，在任务变量表中加上索引（超时问题完美解决。。。。。）