⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/7324296963138863138 「半个工程师一个哲学家」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

场景

在高并发的数据处理场景中，接口响应时间的优化显得尤为重要。本文将分享一个真实案例，其中一个数据量达到200万+的接口的响应时间从30秒降低到了0.8秒内。

这个案例不仅展示了问题诊断的过程，也提供了一系列有效的优化措施。

交易系统中，系统需要针对每一笔交易进行拦截（每一笔支付或转账就是一笔交易），拦截时需要根据定义好的规则拦截，这次需要优化的接口是一个统计规则拦截率的接口。

问题诊断

最初，接口的延迟非常高，大约需要30秒才能完成。为了定位问题，我们首先排除了网络和服务器设备因素，并打印了关键代码的执行时间。经过分析，发现问题出在SQL执行上。

发现Sql执行时间太久，查询200万条数据的执行时间竟然达到了30s，下面是是最耗时的部分相关代码逻辑：

查询代码（其实就是使用Mybatis查询，看起来正常的很）

List<Map<String, Object>> list = transhandleFlowMapper.selectDataTransHandleFlowAdd(selectSql);

统计当天的Id号（programhandleidlist字段）

SELECT programhandleidlist FROM anti_transhandle WHERE create_time BETWEEN '2024-01-08 00:00:00.0' AND '2024-01-09 00:00:00.0';

表结构（Postgresql）

我以为是Sql写的有问题，先拿着sql执行了一边，发现只执行sql的执行时间是大约800毫秒，和30秒差距巨大。

Sql层面分析

使用EXPLAIN ANALYZE函数分析sql。

EXPLAIN ANALYZE
SELECT programhandleidlist FROM anti_transhandle WHERE create_time BETWEEN '2024-01-08 00:00:00.0' AND '2024-01-09 00:00:00.0';

分析结果

看来是代码的部分有问题。

代码层面分析

List<Map<String, Object>> list = transhandleFlowMapper.selectDataTransHandleFlowAdd(selectSql);

Map的Key是programhandleIdList，Map的value是每一行的值。

在Java层面，每条数据都创建了一个Map对象，对于200万+的数据量来说，这显然是非常耗时的操作，速度是被创建了大量的Map集合给拖垮的。。

为了解决这个问题，我们尝试了将200万行数据转换为单行返回，使用PostgreSQL的array_agg和unnest函数来优化查询。

第一次遇到Mybatis查询返回导致接口速度慢的问题。

优化措施

1. SQL优化

我的思路是将200万行转为一行返回。

要将 PostgreSQL 中查询出的 programhandleidlist 字段（假设这是一个数组类型）的所有元素拼接为一行，您可以使用数组聚合函数 array_agg 结合 unnest 函数。

这样做可以先将数组展开为多行，然后将这些行再次聚合为一个单一的数组。如果您希望最终结果是一个字符串，而不是数组，您还可以使用 string_agg 函数。

以下是相应的 SQL 语句：

SELECT array_agg(elem) AS concatenated_array
FROM (
    SELECT unnest(programhandleidlist) AS elem
    FROM anti_transhandle
    WHERE create_time BETWEEN '2024-01-08 00:00:00.0' AND '2024-01-09 00:00:00.0'
) sub;

在这个查询中：

unnest(programhandleidlist) 将 programhandleidlist 数组展开成多行。
string_agg(elem) 将这些行聚合成一个以逗号分隔的字符串。

这将返回一个包含所有元素的单一数组。

查询结果由多行，拼接为了一行。

再测试，现在是正常速度了，但是查询时间依旧很高。Sql查询时间0.8秒，代码中平均1秒8左右，还有优化的空间。

将一列数据转换为了数组类型，查看一下内存占用，这一段占用了54比特，虽然占用不大，但是不知道为什么会mybatis处理时间这么久。

因为mybatis不知道数组的大小，先给数组设定一个初始大小，如果超出了数组长度，因为数组不能扩容，增加长度只能再复制一份到另一块内存中，复制的次数多了也就增加了计算时间。
数据需要在两个设备之间传输，磁盘和网络都需要时间。

2. 部分业务逻辑转到数据库中计算

再次优化sql，将一部分的逻辑放到Sql中处理，减少数据量。

业务上我需要统计programhandleidlist字段中id出现的次数，所以我直接在sql中做统计。

要统计每个数组中元素出现的次数，您需要首先使用 unnest 函数将数组展开为单独的行，然后使用 GROUP BY 和聚合函数（如 count）来计算每个元素的出现次数。这里是修改后的 SQL 语句：

SELECT elem, COUNT(*) AS count
FROM (
    SELECT unnest(programhandleidlist) AS elem
    FROM anti_transhandle
    WHERE create_time BETWEEN '2024-01-08 00:00:00.0' AND '2024-01-09 00:00:00.0'
) sub
GROUP BY elem;

在这个查询中：

unnest(programhandleidlist) 将每个 programhandleidlist 数组展开成多个行。
GROUP BY elem 对每个独立的元素进行分组。
COUNT(*) 计算每个分组（即每个元素）的出现次数。

这个查询将返回两列：一列是元素（elem），另一列是该元素在所有数组中出现的次数（count）。

这条sql在代码中执行时间是0.7秒，还是时间太长，毕竟数据库的数据量太大，搜了很多方法，已经是我能做到的最快查询了。

关系型数据库不适合做海量数据计算查询。

“

这个业务场景牵扯到了海量数据的统计，并不适合使用关系型数据库，如果想要真正的做到毫秒级的查询，需要从设计上改变数据的存储结果。比如使用cilckhouse、hive等存储计算。

3. 引入缓存机制

减少查询数据库的次数，决定引入本地缓存机制。选择了Caffeine作为缓存框架，易于与Spring集成。

分析业务后，当天的统计数据必须查询数据库，但是查询历史日期的采用缓存的方式。如果业务中对时效性不敏感，也可以缓存当天的数据，每隔一段时间更新一次。我这里采用缓存历史日期的数据。

1.引入Caffeine依赖

<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <version>3.1.8</version>
</dependency>

2.配置Caffeine缓存

创建一个专门的Caffeine缓存配置。使用本地缓存选择淘汰策略很重要，由于我的业务场景使根据实现来查询，所以Caffeine将按照最近最少使用（LRU）的策略来淘汰旧数据成符合业务。

import com.github.benmanes.caffeine.cache.Caffeine;
import org.springframework.cache.CacheManager;
import org.springframework.cache.annotation.EnableCaching;
import org.springframework.cache.caffeine.CaffeineCacheManager;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import java.util.concurrent.TimeUnit;

@Configuration
@EnableCaching
public class CacheConfig {
    @Bean
    public CacheManager cacheManager() {
        CaffeineCacheManager cacheManager = new CaffeineCacheManager();
        cacheManager.setCaffeine(Caffeine.newBuilder()
                .maximumSize(500)
                .expireAfterWrite(60, TimeUnit.MINUTES));
        return cacheManager;
    }
}

3.修改ruleHitRate方法来使用Caffeine缓存

在计算昨天命中率的逻辑前加入缓存检查和更新的逻辑。

使用Caffeine缓存：

@Autowired
private CacheManager cacheManager; // 注入Spring的CacheManager

private static final String YESTERDAY_HIT_RATE_CACHE = "hitRateCache"; // 缓存名称

@Override
public RuleHitRateResponse ruleHitRate(LocalDate currentDate) {
    // ... 其他代码 ...

    // 使用缓存获取昨天的命中率
    double hitRate = cacheManager.getCache(YESTERDAY_HIT_RATE_CACHE).get(currentDate.minusDays(1), () -> {
     // 查询数据库
        Map<String, String> hitRateList = dataTunnelClient.selectTransHandleFlowByTime(currentDate.minusDays(1));
       
  // ... 其他代码 ...
  // 返回计算后的结果
        return hitRate;
    });
    // ... 其他代码 ...
}

总结

最后，测试接口，成功将接口从30秒降低到了0.8秒以内。

这次优化让我重新真正审视了关系型数据库的劣势。选择哪种类型的数据库，取决于具体的应用场景和需求。

关系型数据库（Mysql、Oracle等）适合事务性强、数据一致性和完整性要求高的应用。
列式数据库（HBase、ClickHouse等）则适合大数据量的分析和统计，特别是在读取性能方面有显著优势。

此次的业务场景显然更适合使用列式数据库，所以导致使用关系型数据库无论如何也不能够达到足够高的性能。

芋道源码 —— 纯源码解析博客

30s到0.8s，记录一次接口优化成功案例！

场景