AI/BI 仪表板缓存查询结果以提高加载时间。 本页介绍仪表板缓存和数据集优化的工作原理、仪表板使用缓存的结果以及针对 SQL 仓库重新运行查询的时间。
查询性能
您可以在工作区查询历史记录中查看查询及其性能表现。 查询历史记录显示了使用 SQL 仓库执行的 SQL 查询。 单击
，在边栏中选择查询历史记录以查看查询历史记录。 请参阅查询历史记录。
对于仪表板数据集，Azure Databricks 根据数据集的结果大小应用性能优化。 有关数据集性能阈值的信息，请参阅 数据集性能阈值。
数据集优化
仪表板通过尽可能在浏览器中直接执行由筛选器或可视化设置驱动的筛选和聚合操作来优化速度。 这些性能优化具有以下限制：
| 数据集大小 | 处理行为 |
|---|---|
| 小型（≤ 10 万行和 ≤ 100MB） | 为了获得最佳仪表板速度，请在初始数据集加载后在浏览器中运行筛选和聚合。 由于这些作在本地处理，因此它们避免了与数据仓库的进一步交互，并且不会显示在查询历史记录中。 |
| 大型（> 100K 行或 > 100MB） | 筛选和聚合在后端服务器上处理，而不是在浏览器中进行处理。 初始数据集查询包装在 SQL WITH 子句中，生成的查询将显示在查询历史记录中。 |
| 组合查询（大型数据集） | 对于发送到后端的可视化查询，针对共享相同 GROUP BY 子句和筛选谓词的同一数据集的多个单独可视化查询将组合为单个查询以供处理。 在这种情况下，用户可能会在查询历史记录中看到合并的查询，该查询会提取多个可视化效果或筛选器的结果。 |
注释
参数直接在运行时将值替换到查询中，因此这些作始终出现在查询历史记录中。
注释
下载已截断的表会运行查询。 当表因数据集超过 100,000 行而显示被截断的结果时，以 CSV 格式下载数据会针对 SQL 仓库运行查询。 此查询显示在查询历史记录中。
缓存和数据刷新
仪表板维护 24 小时的结果缓存，以优化初始加载时间，并尽最大努力运行。 这意味着，虽然系统总是尝试使用与仪表板凭据相关联的历史查询结果来提高性能，但在某些情况下无法创建或维护缓存结果。 缓存数据没有特定的内存限制，或固定查询计数。
为了优化加载时间，面板首先检查面板缓存。 如果没有可用的缓存结果，则检查通用 查询结果缓存。 这两个缓存以不同的方式失效。 查询结果缓存永远不会返回过时的数据，因为对基础数据的更改会使其所有条目失效。 仪表板缓存的失效行为有所不同。 仪表板缓存可以返回长达 24 小时的结果，即使基础数据已更改，对基础数据的更改也不会自动失效或刷新仪表板缓存。
若要可靠地刷新仪表板缓存，请配置仪表板 计划。 对基础数据的更改不会自行刷新仪表板缓存，在管道步骤中刷新数据不会刷新仪表板缓存。 除按计划刷新外，仪表板缓存仅在仪表板执行了缓存无法处理的查询时才会更新。
注释
从仪表板缓存中提供结果不会启动 SQL 仓库。 当仪表板返回缓存的结果时，Azure Databricks从缓存中读取，而无需运行查询，因此基础 SQL 仓库无需运行。 仅当仪表板运行缓存无法提供服务的查询时，仓库才会启动。
对于多页仪表板，以下内容适用：
- 编辑草稿仪表板加载并缓存所有数据集。
- 查看者打开已发布的仪表板时，仅运行和缓存支持活动页面的数据集。
- 如果设置了计划，则所有数据集会根据计划刷新，并缓存这些结果。
下表说明缓存如何因仪表板状态和凭据而异：
| 仪表板类型 | 缓存类型 |
|---|---|
| 使用共享数据权限发布的仪表板 | 共享缓存。 所有查看者都看到相同的结果。 |
| 草稿仪表板或使用个人数据权限发布的仪表板 | 每个用户的缓存。 查看者根据其数据权限查看结果。 |
如果检索到的结果不到 24 小时，则仪表板会自动使用缓存的查询结果，即使基础数据在上次查询后更改也是如此。 如果存在过时的结果，并且将参数应用到仪表板，则查询会重新执行，除非在过去 24 小时内已使用过相同的参数。 同样，向超过 100,000 行的数据集应用筛选器会提示查询重新运行，除非过去 24 小时内应用了相同的筛选器。
当前时间戳函数和缓存失效
在 current_timestamp() SQL 查询中使用或类似函数不会使仪表板级缓存失效。 但是，这些函数确实使查询结果缓存失效，该缓存会检查 SQL 查询并触发缓存刷新。
计划的查询
将计划添加到使用共享数据权限发布的仪表板可以显著加快所有仪表板查看者的初始加载过程。
对于每个计划的仪表板更新，将发生以下情况：
- 定义数据集的所有 SQL 逻辑都以指定的时间间隔运行。
- 结果会填充查询结果缓存，并帮助改进初始仪表板加载时间。