Java接口性能优化技巧，都是干货……

Part1背景

我负责的系统到2021年初完成了功能上的建设，开始进入到推广阶段。随着推广的逐步深入，收到了很多好评的同时也收到了很多对性能的吐槽。刚刚收到吐槽的时候，我们的心情是这样的：

当越来越多对性能的吐槽反馈到我们这里的时候，我们意识到，接口性能的问题的优先级必须提高了。然后我们就跟踪了1周的接口性能监控，这个时候我们的心情是这样的：

有20多个慢接口，5个接口响应时间超过5s，1个超过10s，其余的都在2s以上，稳定性不足99.8%。作为一个优秀的后端程序员，这个数据肯定是不能忍的，我们马上就进入了漫长的接口优化之路。本文就是对我们漫长工作历程的一个总结。

正文开始！

Part2哪些问题会引起接口性能问题？

这个问题的答案非常多，需要根据自己的业务场景具体分析。这里做一个不完全的总结：

数据库慢查询

深度分页问题

未加索引

索引失效

join过多

子查询过多

in中的值太多

单纯的数据量过大

业务逻辑复杂

循环调用

顺序调用

线程池设计不合理

锁设计不合理

机器问题（fullGC，机器重启，线程打满）

Part3问题解决

1

1、慢查询（基于mysql）1.1 深度分页

所谓的深度分页问题，涉及到mysql分页的原理。通常情况下，mysql的分页是这样写的：

含义当然就是从student表里查100到120这20条数据，mysql会把前120条数据都查出来，抛弃前100条，返回20条。当分页所以深度不大的时候当然没问题，随着分页的深入，sql可能会变成这样：

这个时候，mysql会查出来1000020条数据，抛弃1000000条，如此大的数据量，速度一定快不起来。那如何解决呢？一般情况下，最好的方式是增加一个条件：

这样，mysql会走主键索引，直接连接到1000000处，然后查出来20条数据。但是这个方式需要接口的调用方配合改造，把上次查询出来的最大id以参数的方式传给接口提供方，会有沟通成本（调用方：老子不改！）。

1.2 未加索引

这个是最容易解决的问题，我们可以通过

查看某张表的索引。具体加索引的语句网上太多了，不再赘述。不过顺便提一嘴，加索引之前，需要考虑一下这个索引是不是有必要加，如果加索引的字段区分度非常低，那即使加了索引也不会生效。另外，加索引的alter操作，可能引起锁表，执行sql的时候一定要在低峰期（血泪史！！！！）

1.3 索引失效

这个是慢查询最不好分析的情况，虽然mysql提供了explain来评估某个sql的查询性能，其中就有使用的索引。但是为啥索引会失效呢？mysql却不会告诉咱，需要咱自己分析。大体上，可能引起索引失效的原因有这几个（可能不完全）：

需要特别提出的是，关于字段区分性很差的情况，在加索引的时候就应该进行评估。如果区分性很差，这个索引根本就没必要加。区分性很差是什么意思呢，举几个例子，比如：

某个字段只可能有3个值，那这个字段的索引区分度就很低。

再比如，某个字段大量为空，只有少量有值；

再比如，某个字段值非常集中，90%都是1，剩下10%可能是2,3,4....

进一步的，那如果不符合上面所有的索引失效的情况，但是mysql还是不使用对应的索引，是为啥呢？这个跟mysql的sql优化有关，mysql会在sql优化的时候自己选择合适的索引，很可能是mysql自己的选择算法算出来使用这个索引不会提升性能，所以就放弃了。这种情况，可以使用force index 关键字强制使用索引（建议修改前先实验一下，是不是真的会提升查询效率）：

其中xxxx是索引名。

1.4 join过多 or 子查询过多

我把join过多 和子查询过多放在一起说了。一般来说，不建议使用子查询，可以把子查询改成join来优化。同时，join关联的表也不宜过多，一般来说2-3张表还是合适的。具体关联几张表比较安全是需要具体问题具体分析的，如果各个表的数据量都很少，几百条几千条，那么关联的表的可以适当多一些，反之则需要少一些。

另外需要提到的是，在大多数情况下join是在内存里做的，如果匹配的量比较小，或者join_buffer设置的比较大，速度也不会很慢。但是，当join的数据量比较大的时候，mysql会采用在硬盘上创建临时表的方式进行多张表的关联匹配，这种显然效率就极低，本来磁盘的IO就不快，还要关联。

一般遇到这种情况的时候就建议从代码层面进行拆分，在业务层先查询一张表的数据，然后以关联字段作为条件查询关联表形成map，然后在业务层进行数据的拼装。一般来说，索引建立正确的话，会比join快很多，毕竟内存里拼接数据要比网络传输和硬盘IO快得多。

1.5 in的元素过多

这种问题，如果只看代码的话不太容易排查，最好结合监控和数据库日志一起分析。如果一个查询有in，in的条件加了合适的索引，这个时候的sql还是比较慢就可以高度怀疑是in的元素过多。一旦排查出来是这个问题，解决起来也比较容易，不过是把元素分个组，每组查一次。想再快的话，可以再引入多线程。

进一步的，如果in的元素量大到一定程度还是快不起来，这种最好还是有个限制

当然了，最好是在代码层面做个限制

1.6 单纯的数据量过大

这种问题，单纯代码的修修补补一般就解决不了了，需要变动整个的数据存储架构。或者是对底层mysql分表或分库+分表；或者就是直接变更底层数据库，把mysql转换成专门为处理大数据设计的数据库。这种工作是个系统工程，需要严密的调研、方案设计、方案评审、性能评估、开发、测试、联调，同时需要设计严密的数据迁移方案、回滚方案、降级措施、故障处理预案。除了以上团队内部的工作，还可能有跨系统沟通的工作，毕竟做了重大变更，下游系统的调用接口的方式有可能会需要变化。

出于篇幅的考虑，这个不再展开了，笔者有幸完整参与了一次亿级别数据量的数据库分表工作，对整个过程的复杂性深有体会，后续有机会也会分享出来。