根据开发人员的表述：这个SQL经过优化后，在功能测试环境是没问题了，但是放在性能测试环境又出现了超时现象。同样的SQL，更好的配置，更差的性能，不用说，这肯定又是数据量导致的。果真，在性能环境主表rp_task_t表的数据量已经达到了5000万，res_cnfg表的数据量也接近5000万，不慢才怪。那么到底是哪个步骤导致了性能慢呢？因为时间充裕，我又回到自己的节奏，先不看执行计划，先看SQL语句，逐行逐行的看：
1、 SELECT部分：没问题，因为都是简单的字段，并没有涉及到函数或子查询；
2、 From部分：通过上次的优化，基本上也没有问题；
3、 Where部分：这部分是没有优化过的，就如第一次优化提到的，这部分是畸形的，而前三次优化都没有涉及到，可见这个疏忽是多么的可怕
最先吸引我的是exists，有没有发现，这个项目对exists特别的情有独钟，感觉如果一个SQL钟没有用exists，好像会显得很寒碜，而一用exists就显得高大上了。这个SQL的exists也一样，除了在第三次优化去掉了两个exists外，在where中还存在三个exists语句，并且存在exists套exists的现象，套也就算了，毕竟有业务要求，但关键是你还套重复了。我们来看下这个exists：
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/693533/viewspace-1983406/ ，如需转载，请注明出处，否则将追究法律责任。
