大数据量查询计算引发数据库CPU告警问题复盘

一、背景

2025年7月份某天，CDP系统每天不定时推送我们的Portal服务，生产环境运营看板会展示统计数据，发现接口响应缓慢，随之而来数据库监控告警，发现数据库CPU达到了80%。由于表数据量大，计算统计复杂，多线程使用不当，导致数据库服务器爆表。
其中A表数据量达到1亿多，B表数据量600w+，C表数据量30w+，D表数据量400w+.

二、根因分析

1：涉及A、B、C、D四张表的关联查询，数据量巨大。
2：页面查询条件组合较多，初步估计数据量10亿+，而且日期条件多变，无法使用预计算方式提升查询效率。
3：CDP不定时同步，导致每次存量数据无法基线，增量数据的统计依赖于存量数据，故无法使用增量方式计算结果。
4：1次查询搜索，会调用6个接口，1个接口查询数据库6+次，整体耗时较久。

三、解决方案

方案1：多线程+缓存

1：前端查询接口，先查询缓存，如果查询到则直接返回结果。如果查询不到，再查询缓存并将结果更新到缓存中。
2：在后端接口计算中，采用多线程方式，并行计算，然后再统计结果。
3：但是这个方案有个弊端是在缓存中查询不到时候还会查询数据库，接口响应依然缓慢，而且生产环境会产生许多慢SQL。所以，此方案不采纳。

方案2：利用中间表+缓存

1：分析这四张表发现，最大的表A仅仅起到连接的作用，运营看板计算数据主要来自于B表数据量600w+和C表数据量30w+。因此，新增E表，将所需要的A表与D表的关联数据通过定时任务方式同步到E表，最后E表中数据量为400w+，相比与直接关联A表和D表，数据量整体降低了几百万，后续直接关联查询B表数据量600w+、C表数据量30w+和E表400w计算即可。
2：前端查询接口，先查询缓存，如果查询到则直接返回结果。如果查询不到，再查询缓存并将结果更新到缓存中。

四、总结

采用空间换时间方式，优化了大表关联查询性能，也是一种不错的方案。