前言

接口性能优化对于从事后端开发的同学来说，或加个索引就能解决问题，或需要做代码重构，或需要增加缓存，或需要引入一些中间件，比如 mq，或需要分库分表，或需要拆分服务。。。

导致接口性能问题的原因千奇百怪，不同的项目不同的接口，原因可能也不一样。

我们一起来讨论以下行之有效的优化接口性能的办法：

1.索引

接口性能优化最先想到的可能是：优化索引，因为其优化成本是最小的，可通过查看线上日志或者监控报告，筛查出某个接口调用的某条SQL语句耗时问题。

排查时一般从以下几点进行：

1. SQL语句加索引了没？

2. 加的索引生效了没？

3. mysql 选错索引了没？

1.1 无索引 情况下

在项目中很常见的问题：SQL语句中忘了where条件的关键字段，或者order by后面的排序字段加索引。

项目初期由于表中的数据量小，无索引 SQL查询也不会引起大的性能问题。

但随着业务壮大，表中数据量越来越多，就不得不加索引了。

show index from `table_name`;

能单独查看某张表的索引情况。

show create table `table_name`;

查看整张表的建表语句，里面也会展示索引情况。

如果无索引，则可以通过ALTER TABLE命令，或者CREATE INDEX命令添加索引：

ALTER TABLE `table_name` ADD INDEX idx_name ( field_name );或者CREATE INDEX idx_name ON `table_name` (field_name);

目前在 mysql 中，想要修改索引则只能先删除索引后，再重新添加新的索引。其中删除索引方式有2种：ALTER TABLE命令、DROP INDEX命令

ALTER TABLE `table_name` DROP INDEX idx_name;或者DROP INDEX idx_name ON `table_name`;

1.2 添加的索引没生效

show index from `table_name`;

通过查询得知有索引，但它生效了没？如何进行查看索引有没有生效呢？

explain select * from `table_name` where code='002';

是的，用explain命令来查看 mysql 的执行计划，它会显示索引的使用情况。

这几列就可以判断索引使用情况：

那么你知道索引失效的常见原因吗？

如果上面2个都没问题，则需要进一步排查其他原因。

1.3 选错索引

常常有这种情况：同一条SQL，只有入参不同而已，但有时走的索引 a，有时却走的索引 b？

必要时则可用force index来强制查询SQL走某个索引。

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：691998057【暗号：csdn999】

2. SQL 优化

如果优化索引后也对性能改变不大，则试着优化一下SQL语句，在这列举了 SQL优化的小技巧，共15种：

3. 远程调用

很多时候，我们需要在某个接口中，调用其他服务的接口。

有这样的业务场景：

用户信息查询接口中需要返回：用户名称、性别、等级、头像、成长值、积分等信息。

而用户名称、性别、等级、头像在用户服务中，成长值在成长值服务中，积分在积分服务中。为了汇总这些数据统一返回，需要另外提供一个对外接口服务。

这种业务场景下，我们就需要在某个接口中，调用其他服务的接口，即用户信息查询接口需要调用用户查询接口、成长值查询接口和积分查询接口，然后汇总数据统一返回。

如此计算，串行调用接口总耗时200ms + 150ms + 180ms = 530ms。

针对该情况，如何优化远程接口性能呢？

3.1 并行调用

既然串行调用多个远程接口性能很差，那我们可以改成并行调用：

这样则只需要取即耗时最长远程接口调用。
 

4. 重复调用

重复调用在代码中如果没有控制好，会非常影响接口的性能，此时应减少代码运行重复。

5. 异步处理

接口性能优化，需要重新梳理一下业务逻辑，是否有设计不合理。比如有个用户请求接口中，需要做业务操作、发站内通知和记录操作日志。为了实现起来比较方便，通常会将这些逻辑放在接口中同步执行，接口内部流程图如下：

这个接口表面上看起来没有问题，但如果你仔细梳理一下业务逻辑，会发现只有业务操作才是核心逻辑，其他的功能都是非核心逻辑。

在这里有个原则就是：核心逻辑可以同步执行，同步写库。非核心逻辑，可以异步执行，异步写库。

上面这个例子中，发站内通知和用户操作日志功能，对实时性要求不高，即使晚点写库，用户无非是晚点收到站内通知，或者运营晚点看到用户操作日志，对业务影响不大，所以完全可以异步处理。

通常异步主要有两种：多线程 和 mq。

5.1 线程池

使用线程池改造之后，接口逻辑如下：

发站内通知和用户操作日志功能，被提交到了两个单独的线程池中。

这样接口中重点关注的是业务操作，把其他的逻辑交给线程异步执行，这样改造之后，让接口性能瞬间提升了。

但使用线程池有个小问题就是：如果服务器重启了，或者是需要被执行的功能出现异常了，无法重试，会丢数据。

5.2 mq

使用mq改造之后，接口逻辑如下：

对于发站内通知和用户操作日志功能，在接口中并没真正实现，它只发送了 mq 消息到 mq 服务器。然后由 mq 消费者消费消息时，才真正地执行这两个功能。

6. 避免大事务

在使用 spring 框架开发项目时使用@Transactional注解提供事务功能，但也容易造成大事务，引发其他的问题。

看看大事务引发的问题：

大事务问题可能会造成接口超时，对接口的性能有直接的影响，遇到这类问题，往往这样优化：

1. 少用 @Transactional 注解

2. 将查询(select)方法放到事务外

3. 事务中避免远程调用

4. 事务中避免一次性处理太多数据

5. 有些功能可以非事务执行

6. 有些功能可以异步处理

7. 锁粒度

在某些业务场景中，多个线程并发修改某个共享数据，会造成数据异常。

为了解决并发场景下，多个线程同时修改数据造成数据不一致的情况，通常情况下，我们会：加锁。

但如果锁加得不好，导致锁的粒度太粗，也会非常影响接口性能。

redis 分布式锁虽说好用，但它在使用时，有很多注意的细节，隐藏了很多坑，如果稍不注意很容易踩中。redis 分布式锁的 8 大坑具体如下：

mysql 数据库中主要有三种锁：

• 表锁：加锁快，不会出现死锁。但锁的粒度大，发生锁冲突的概率最高，并发度最低。

• 行锁：加锁慢，会出现死锁。但锁的粒度最小，发生锁冲突的概率最低，并发度也最高。

• 间隙锁：开销和加锁时间界于表锁和行锁之间。它会出现死锁，锁的粒度界于表锁和行锁之间，并发度一般。

并发度越高，意味着接口性能越好。

所以数据库锁的优化方向是：优先使用行锁，其次使用间隙锁，再其次使用表锁。

8.分页处理

有时，我们会调用某个接口批量查询数据，这样一个场景：通过用户 id 批量查询出用户信息，然后给这些用户送积分。

但如果你一次性查询的用户数量太多了，比如一次查询 2000 个用户的数据。参数中传入了 2000 个用户的 id，远程调用接口，会发现该用户查询接口经常超时。

众所周知，调用接口从数据库获取数据，是需要经过网络传输的。如果数据量太大，无论是获取数据的速度，还是网络传输受限于带宽，都会导致消耗时间比较长。

那么，这种情况就需要分页处理。

将一次获取所有数据的请求，改成分多次获取，每次只获取一部分用户的数据，最后进行合并和汇总。

其实，处理这个问题，要分为两种场景：同步调用 和 异步调用。

9.加缓存

加缓存是解决接口性能问题一个非常高效的方法。

但也需要视情况而定，加了缓存会导致接口的复杂度增加，它从而可能数据不一致。

在有些并发量比较低的场景中，比如用户下单，可以不用加缓存。

还有些场景，比如在商城首页显示商品分类的地方，假设这里的分类是调用接口获取到的数据，但页面暂时没有做静态化。

如果查询分类树的接口没有使用缓存，而直接从数据库查询数据，性能会非常差。

10. 分库分表

有时候，接口性能受限的不是别的，而是数据库。

当系统发展到一定的阶段，用户并发量大，会有大量的数据库请求，需要占用大量的数据库连接，同时会带来磁盘 IO 的性能瓶颈问题。

此外，随着用户数量越来越多，产生的数据也越来越多，一张表有可能存不下。由于数据量太大，sql 语句查询数据时，即使走了索引也会非常耗时。

这时就需要做分库分表：

分库分表主要有两个方向：垂直和水平，垂直方向（即业务方向）更简单。

在水平方向（即数据方向）上，分库和分表的作用，其实是有区别的，不能混为一谈。

• 分库：为了解决数据库连接资源不足、磁盘 IO 的性能瓶颈问题。

• 分表：为了解决单表数据量太大，SQL语句查询数据时即使走了索引也非常耗时问题。此外也会解决消耗CPU资源问题。

• 分库分表：可解决数据库连接资源不足、磁盘IO的性能瓶颈、检索数据耗时和消耗CPU资源等问题。

若用户并发量很大，但是需要保存的数据量很少，这时只分库、不分表；

若用户并发量不大，但是需要保存的数量很多，这时只分表、不分库；

若用户并发量大，并且需要保存的数量也很多时，可以分库分表。

11. 辅助功能

优化接口性能问题，除了上面提及到的常用方法，也需要配合使用一些辅助功能，如

11.1 开启慢查询日志

为了定位 sql 的性能瓶颈，开启 mysql 的慢查询日志就能把超过指定时间的 sql 语句，单独记录下来，方面以后分析和定位问题。

通过 mysql 的set命令可以设置三个参数：

set global slow_query_log='ON';  //慢查询开关
set global slow_query_log_file='/usr/local/mysql/data/slow.log'; //慢查询日志存放的路径
set global long_query_time=2; //超过多少秒才会记录日志

如上设置，如果某条SQL执行时间超过了 2 秒，会被自动记录到 slow.log 文件中。

还有一种简单粗暴的方式，直接修改配置文件my.cnf。

[mysqld]slow_query_log = ONslow_query_log_file = /usr/local/mysql/data/slow.loglong_query_time = 2

11.2 加监控

目前业界使用比较多的开源监控系统是：Prometheus。可以用它监控如下信息：

• 接口响应时间

• 调用第三方服务耗时

• 慢查询 sql 耗时

• cpu 使用情况

• 内存使用情况

• 磁盘使用情况

• 数据库使用情况

下面是配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！

最后： 可以在公众号：程序员小濠 ！ 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！