我用Doris SQL Cache拯救了每日早会，太绝了！

一臻数据

发布于 2025-02-12 15:15:30

9400

代码可运行

运行总次数：0

代码可运行

❝"小张，这个SQL怎么跑了5分钟还没出结果？" "我明明昨天查过这个数据，怎么今天又要等这么久？" "早会马上开始了，报表还在加载中..." 这些吐槽是否让你感同身受？作为一名DBA或数据工程师，你一定经历过被用户"围攻"的尴尬时刻。面对重复的查询需求，系统却像一位"健忘症患者"，每次都要重新计算，这着实让人抓狂。不过，今天我要介绍一位特别的"记忆大师" —— Doris SQL Cache，能够智能记住查询结果，让重复查询变得行云流水。从此，告别反复计算的烦恼，让你的系统性能起飞！

Doris的高效缓存引擎

每天早上9点，运营同事都会查询昨天的销售数据，每个人都在跑相同的SQL，系统压力山大。看着日益增长的并发请求，DBA表示很头疼...

在数据分析领域，重复查询是一个普遍现象。小王每天查看销售报表，小李每天统计用户增长，这些查询逻辑往往大同小异。如果每次查询都要重新计算，岂不是太浪费资源了？

Doris的SQL Cache好比一台懂事的咖啡机。第一杯咖啡需要现磨现煮，之后的咖啡就能直接享用了。它通过智能缓存查询结果，大幅提升查询性能。

当查询请求到达时，Doris会进行一系列精确的匹配：SQL文本是否相同？表的版本是否变化？权限是否一致？ 就像咖啡师在确认你的口味和要求。只有所有条件都匹配，才能享受到缓存带来的快速响应。

我们来看一个销售数据分析的场景：

-- 设置当前会话开启SQL Cache
set enable_sql_cache=true;

-- 分析昨日销售数据
SELECT 
    province,
    SUM(sales_amount) as total_sales,
    COUNT(DISTINCT user_id) as buyer_count
FROM sales_detail 
WHERE dt = '2025-02-09'
GROUP BY province;

第一次执行这个查询时，Doris会从BE节点获取数据并计算。之后相同的查询就能直接从缓存获取结果，响应时间从秒级降至毫秒级。这对于每天早上的销售分析报表简直就是一剂强心针。

Doris让缓存可管可控

光有缓存机制还不够，Doris还提供了丰富的SQL Cache监控指标，方便用户进行有效监控。

通过FE的HTTP接口，我们能看到缓存的命中次数：

# FE 的 HTTP 接口 http://${FE_IP}:${FE_HTTP_PORT}/metrics

# 代表已经把 1 个 SQL 写入到缓存中
doris_fe_cache_added{type="sql"} 1

# 代表命中了两次 SQL Cache
doris_fe_cache_hit{type="sql"} 2

通过BE的指标，我们能掌握缓存占用的内存大小：

#  BE 的 HTTP 接口 http://${BE_IP}:${BE_HTTP_PORT}/metrics

# 代表当前 BE 的内存中存在 1205 个 Cache
doris_be_query_cache_sql_total_count 1205

# 当前所有 Cache 占用 BE 内存 44k
doris_be_query_cache_memory_total_byte 44101

这些数据好比是给缓存装上了个"体检仪"，让我们随时掌握它的健康状况。

为了避免缓存过度占用内存，Doris还提供了灵活的内存控制机制：

1. FE 内存控制

-- 最多存放 100 个 Cache 元数据，超过时自动释放最近最久未使用的元数据。默认值为 100。  
ADMIN SET FRONTEND CONFIG ('sql_cache_manage_num'='100');  
  
-- 当 300 秒未访问该 Cache 元数据后，自动进行释放。默认值为 300。  
ADMIN SET FRONTEND CONFIG ('expire_sql_cache_in_fe_second'='300');

-- 默认超过 3000 行结果时，不创建 SQL Cache。  
ADMIN SET FRONTEND CONFIG ('cache_result_max_row_count'='3000');  
  
-- 默认超过 30M 时，不创建 SQL Cache。  
ADMIN SET FRONTEND CONFIG ('cache_result_max_data_size'='31457280');

2. BE 内存控制

-- 当 Cache 的内存空间超过 query_cache_max_size_mb + query_cache_elasticity_size_mb 时，  
-- 释放最近最久未使用的 Cache，直至占用内存低于 query_cache_max_size_mb。  
query_cache_max_size_mb = 256  
query_cache_elasticity_size_mb = 128

这不就是给咖啡机设置了储水量上限，既保证了性能，又避免了资源浪费。

实践案例，化腐朽为神奇

回到开头。小张是某电商平台的DBA，遇到了一个棘手的问题：每天早上9点，系统CPU使用率飙升到90%，响应时间从毫秒级飙升到秒级。经过排查发现，这个时间点有大量运营人员在查询昨日销售数据。

让我们看看小张如何借助Doris SQL Cache发挥最大效力：

时间窗口优化

销售数据分析中，我们经常会用到now()函数获取当前时间。每一秒钟，这个函数的返回值都在变化，导致缓存频繁失效。聪明的做法是把时间粒度调整得更粗一些：

-- 优化前：缓存效果差
SELECT * FROM sales WHERE create_time > now();

-- 优化后：一天内都能复用缓存
SELECT * FROM sales WHERE dt = DATE(now());

查询模式优化

在报表分析场景中，我们常常需要统计各种维度的数据。与其每个维度单独查询，不如把相关维度的统计合并到一个查询中：

-- 优化前：多次查询，缓存效果差
SELECT COUNT(*) FROM orders WHERE dt='2025-02-08';
SELECT SUM(amount) FROM orders WHERE dt='2025-02-08';

-- 优化后：一次查询，充分利用缓存
SELECT 
    COUNT(*) as order_count,
    SUM(amount) as total_amount 
FROM orders 
WHERE dt='2025-02-08';

...