1、先使用一些集成测试插件（比如jmeter、metershpere）或者脚本定位到慢速接口，也可以通过日志分析cat | grep
2、使用sonar、findbugs之类的插件定位复杂度较高的代码，（分析一下算法复杂度和空间复杂度）以及sql调用部分的代码
3、先将调用的sql放到mysql上运行一遍，观测执行速度，如果存在慢速sql，先优化它（这一步也可以通过慢查询日志或者sonar提前或者事后检测）
4、该加索引的加索引、简化sql的简化sql，可以使用explain查询计划分析索引使用情况
5、如果单靠sql的优化无法解决问题，就使用多个线程分开查询数据，最后统计完成返回。原则上如果使用微服务的架构，尽量不出现三张表以上的联查。web端编写sql原则上尽量简单易用、易维护，尽量不写复杂sql和动态查询之类的复用，宁愿多写几条sql用。
(
为什么可以用java多线程调用再整合优化复杂sql呢，因为java是基于已查询好的sql数据，不需要想sql一样分析sql再计算表连接，java直接将数据读进内存，一般是比sql扫描全表数据要快的，for循环匹配的效率本质上可能和join计算的效率一样。快就快在java读进内存操作的数据比sql要少很多，最后整合的效率可能会被sql分析、计算表连接之类的操作抵消掉
)
6、如果代码和sql都优化到极致还是不满意，使用redis缓存，先对一些常用且不会变化的表进行缓存和双写一致，比如系统表、用户表、字典表
7、sql部分优化完成，依然效率低，开始解读代码部分。for循环的嵌套层数，需不需要forjoin来解决
8、最后、以上操作均不能提高效率，那就考虑整体缓存接口数据，做好一致性策略。再不行问产品需求合不合理
标签：架构,代码,查询,判定,代码执行,sql,java,优化,效率 From： https://www.cnblogs.com/benjerry/p/17552627.html