---
url: /v6.2/performance-faq.md
---
# 性能与实时性

很多“性能问题”其实混合了三件不同的事：查询慢、页面慢、以及“为什么数据不是实时的”。这页把最常见的误区和判断方法先讲清楚。

## 开启加速引擎后，为什么数据看起来不实时了？

因为加速引擎的价值就是把结果固化下来，换取更稳定、更快的查询性能。它并不是“既保留完全实时，又免费加速”的开关。

所以如果你打开了加速引擎，发现源库更新后页面没有立刻反映，先不要把它当成异常；这通常是加速路径本身的预期结果。

## 既想快，又希望尽量接近实时，应该怎么选？

通常按下面方式判断：

|场景|更推荐的方式|
|-|-|
|数据量不大、源库算力足够、必须实时看最新数据|优先直连查询|
|跨数据源、计算复杂、源库扛不住实时分析|考虑数仓 / 数据集成，把结果按计划同步|
|访问量高、查询重复度高|配合图表缓存周期|

如果你遇到的是“引擎不实时，但直连又太慢”，更适合在**数据集成 + 执行计划**上做平衡，而不是继续强压单次实时查询。

## 一个仪表盘为什么会越做越慢？

最常见的原因有：

1. 单页 Chart 太多，后端查询和前端渲染压力一起上涨
2. 过滤器候选值过大，尤其直接从事实表取过滤器
3. 高去重值字段被拿来做维度、对比维度或大范围筛选
4. Fusion / 联合 / 聚合 / 合并链路层数太深
5. 用户频繁手动刷新，绕过缓存重复打到数据源

如果你只是看到“页面转圈”，不要只盯着数据库，还要一起看页面里到底挂了多少 Chart、多少过滤器、多少联动。

## 提高图表加载速度，优先该改什么？

优先顺序通常是：

1. 控制单个仪表盘内 Chart 数量
2. 过滤器尽量走维度表，不要直接从事实表拉大列表
3. 降低高基数字段在展示与筛选中的直接使用
4. 合理设置图表数据缓存周期
5. 设计阶段启用采样查询，提升制作效率

如果你还没做这些，就先不要直接把问题归因到“产品性能不够”。

## 浏览器打开页面慢，和数据查询慢是一回事吗？

不是。

* **查询慢**：更多是数据源、SQL、数据集、缓存策略的问题
* **页面慢**：还可能叠加资源传输、前端渲染、反向代理配置的问题

如果页面资源传输慢，建议同时检查反向代理是否开启了 **HTTP/2** 与 **gzip**。这类优化不会改变查询逻辑，但会明显影响最终页面体感。

进一步阅读：

* [产品使用性能问题指引](solutions-use-performance.md)
* [反向代理注意事项](post-deployment.md#反向代理注意事项)