性能与实时性
很多“性能问题”其实混合了三件不同的事：查询慢、页面慢、以及“为什么数据不是实时的”。这页把最常见的误区和判断方法先讲清楚。
开启加速引擎后，为什么数据看起来不实时了？
因为加速引擎的价值就是把结果固化下来，换取更稳定、更快的查询性能。它并不是“既保留完全实时，又免费加速”的开关。
所以如果你打开了加速引擎，发现源库更新后页面没有立刻反映，先不要把它当成异常；这通常是加速路径本身的预期结果。
既想快，又希望尽量接近实时，应该怎么选？
通常按下面方式判断：
| 场景 | 更推荐的方式 |
|---|---|
| 数据量不大、源库算力足够、必须实时看最新数据 | 优先直连查询 |
| 跨数据源、计算复杂、源库扛不住实时分析 | 考虑数仓 / 数据集成，把结果按计划同步 |
| 访问量高、查询重复度高 | 配合图表缓存周期 |
如果你遇到的是“引擎不实时，但直连又太慢”，更适合在数据集成 + 执行计划上做平衡，而不是继续强压单次实时查询。
一个仪表盘为什么会越做越慢？
最常见的原因有：
- 单页 Chart 太多，后端查询和前端渲染压力一起上涨
- 过滤器候选值过大，尤其直接从事实表取过滤器
- 高去重值字段被拿来做维度、对比维度或大范围筛选
- Fusion / 联合 / 聚合 / 合并链路层数太深
- 用户频繁手动刷新，绕过缓存重复打到数据源
如果你只是看到“页面转圈”，不要只盯着数据库，还要一起看页面里到底挂了多少 Chart、多少过滤器、多少联动。
提高图表加载速度，优先该改什么？
优先顺序通常是：
- 控制单个仪表盘内 Chart 数量
- 过滤器尽量走维度表，不要直接从事实表拉大列表
- 降低高基数字段在展示与筛选中的直接使用
- 合理设置图表数据缓存周期
- 设计阶段启用采样查询，提升制作效率
如果你还没做这些，就先不要直接把问题归因到“产品性能不够”。
浏览器打开页面慢，和数据查询慢是一回事吗？
不是。
- 查询慢：更多是数据源、SQL、数据集、缓存策略的问题
- 页面慢：还可能叠加资源传输、前端渲染、反向代理配置的问题
如果页面资源传输慢，建议同时检查反向代理是否开启了 HTTP/2 与 gzip。这类优化不会改变查询逻辑，但会明显影响最终页面体感。
进一步阅读：