Documentation

优化查询

优化SQL和InfluxQL查询以提高性能,降低它们的内存和计算(CPU)需求。了解如何使用可观察性工具来分析查询执行并查看指标。

为什么我的查询这么慢?

查询性能取决于时间范围和查询复杂性等因素。
如果查询比预期慢,请考虑以下潜在原因:

  • 查询跨越了很长的时间范围,这增加了被处理的数据量。
  • 查询执行密集型操作,如:
    • 使用 ORDER BY 对大数据集进行排序或重新排序。
    • 查询多个字符串值,这可能是计算上昂贵的。

提高查询性能的策略

以下设计策略通常可以提高查询性能和资源使用:

仅查询您需要的数据

包含一个 WHERE 子句

InfluxDB 3 为每个分区存储数据在一个 Parquet 文件中。 默认情况下,InfluxDB 按天对聚簇分区进行表格化,但你也可以 自定义分区数据。 在查询时,InfluxDB 从对象存储中检索文件以回答查询。 为了减少查询需要从对象存储中检索的文件数量, 包括一个 WHERE 子句,它 通过时间范围或特定标签值过滤数据。

仅选择您所需的列

因为 InfluxDB 3 是一个列式数据库,它只处理在查询中选择的列,这可以减轻 宽模式 对查询性能的影响。

然而,一个从宽模式中检索大量列的非特定查询可能比更有针对性的查询更慢且效率更低——例如,考虑以下查询:

  • SELECT time,a,b,c
  • SELECT *

如果表包含10列,则两个查询之间的性能差异很小。 在一个超过1000列的表中,SELECT * 查询速度较慢,效率较低。

识别和解决瓶颈

要识别性能瓶颈,学习如何 分析查询计划。查询计划提供运行时度量,例如扫描的文件数量,这可能揭示查询执行中的低效之处。

请求帮助以解决查询问题

一些瓶颈可能源于次优的查询 执行计划,并且在您的控制范围之外——例如:

  • 对已经排序的数据进行排序 (ORDER BY)。
  • 从对象存储中检索大量小的Parquet文件,而不是较少的较大文件。
  • 查询许多重叠的Parquet文件。
  • 执行高数量的表扫描。

如果您已按照步骤优化排查查询问题,但仍然未满足性能要求,请查看如何报告查询性能问题

查询跟踪日志

目前,客户无法为InfluxDB集群启用跟踪日志记录。 InfluxData工程师可以使用查询计划和跟踪日志记录来帮助确定查询中的性能瓶颈。

查看如何报告查询性能问题



Flux的未来

Flux 正在进入维护模式。您可以像现在一样继续使用它,而无需对您的代码进行任何更改。

阅读更多

InfluxDB 3 开源版本现已公开Alpha测试

InfluxDB 3 Open Source is now available for alpha testing, licensed under MIT or Apache 2 licensing.

我们将发布两个产品作为测试版的一部分。

InfluxDB 3 核心,是我们新的开源产品。 它是一个用于时间序列和事件数据的实时数据引擎。 InfluxDB 3 企业版是建立在核心基础之上的商业版本,增加了历史查询能力、读取副本、高可用性、可扩展性和细粒度安全性。

有关如何开始的更多信息,请查看: