一、背景

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：前端查詢接口，先查詢緩存，如果查詢到則直接返回結果。如果查詢不到，再查詢緩存并將結果更新到緩存中。

四、總結

采用空間換時間方式，優化了大表關聯查詢性能，也是一種不錯的方案。