背景
今天领导给了个任务，页面上有个功能请求接口特别慢，需要优化一下，哇，又是充满希望的一天！
问题排查
打开F12看接口的执行时间，妈耶，执行了6.22秒，如果任务以来很多的话，那岂不是更慢，怪不得有些用户反映接口慢的要命。
用arthas(阿尔萨斯)排查接口中的慢方法，开启arthas,选择需要监控的服务
trace命令格式:
trace 全路径类名 方法名
执行trace com.dtstack.batch.service.job.impl.BatchJobJobService displayDffSpring，如图所示：
我多触发了几下该接口，妈耶，执行了27s，从图中可以看到是com.dtstack.batch.service.job.impl.BatchJobJobService类的getSpecifiedLevelJobJobs方法慢，占了总时间的99%，ctrl+c退出此监控，输入
trace com.dtstack.batch.service.job.impl.BatchJobJobService getSpecifiedLevelJobJobs
从图中发现基本上是com.dtstack.batch.dao.BatchJobJobDao类的listByParentJobKeysWithOutSelfTask方法慢，此时此刻，我微微一笑，就这？就这？问题找到了，这不就是sql优化嘛，好吧，搞起
大眼一瞟，这啥年代了，写sql还用not in,咋想的，想害朕？
执行一下sql看看运行时长，5s多!
explain查看sql执行计划
如我所愿，确实是因为not in 导致没用到索引，而且这两张表会越来越大，且目前都是百万级别的表。
问题解决
开发人员一般都知道开发的时候要用not exists来代替，更改sql后执行，瞬间出结果，explain查看执行计划：
打个版，看一下效果。
看看，从秒级到毫秒级的质变，问题就此解决！
总结
老铁们，写这篇文章是为了给大家一些解决问题的思路，希望对大家有所帮助！！！也许，这就是技术人员仅有的那点虚荣心吧，加油！