使用 ES|QL 查询多个索引

使用 ES|QL，你可以在多个 索引、数据流、别名、视图 或 子查询 之间执行单个查询。为此，请使用逗号分隔的列表、通配符和日期算术。以下示例使用了逗号分隔的列表和通配符

FROM employees-00001,other-employees-*
		

使用格式 <remote_cluster_name>:<target> 来 查询远程集群上的数据流和索引

FROM cluster_one:employees-00001,cluster_two:other-employees-*
		

在 Elastic Stack 中，你必须始终显式指定目标索引、数据流或别名。

在 Serverless 中，默认情况下，查询会自动通过 跨项目搜索 (CPS) 在所有链接的项目中运行。空间级设置以及用户或 API 密钥权限也会影响包含哪些项目。

当查询多个索引、数据流、别名、视图或子查询时，你可能会发现同一个字段被映射到了多个不同的类型。例如，考虑具有以下字段映射的两个索引

index: events_ip

{
  "mappings": {
    "properties": {
      "@timestamp":     { "type": "date" },
      "client_ip":      { "type": "ip" },
      "event_duration": { "type": "long" },
      "message":        { "type": "keyword" }
    }
  }
}
		

index: events_keyword

{
  "mappings": {
    "properties": {
      "@timestamp":     { "type": "date" },
      "client_ip":      { "type": "keyword" },
      "event_duration": { "type": "long" },
      "message":        { "type": "keyword" }
    }
  }
}
		

当你使用像 FROM events_ip 这样的简单查询分别查询它们时，返回的结果会带有特定于类型的列

FROM events_ip
| SORT @timestamp DESC
		

请注意 client_ip 列是如何被正确识别为 ip 类型的，并且所有值都得以显示。但是，如果查询改用 FROM events_* 从两个冲突的索引获取数据，则无法确定 client_ip 列的类型，系统会将其报告为 unsupported，并且所有返回值均为 null。

FROM events_*
| SORT @timestamp DESC
		

此外，如果查询直接引用此不受支持的字段，查询将会失败

FROM events_*
| SORT client_ip DESC
		

Cannot use field [client_ip] due to ambiguities being mapped as
[2] incompatible types:
    [ip] in [events_ip],
    [keyword] in [events_keyword]
		

ES|QL 提供了一种处理 字段类型不匹配 的方法。当同一个字段在多个索引中被映射为多个不同的类型时，该字段的类型被视为索引映射中各种类型的联合（union）。正如前面的示例所示，此联合类型不能用于结果中，也不能被查询引用，除非在 KEEP、DROP 中，或者当它被传递给一个类型转换函数时——该函数接受联合中的所有类型并将该字段转换为单一类型。ES|QL 提供了一套 类型转换函数 来实现这一点。

在上述示例中，查询可以使用诸如 EVAL client_ip = TO_IP(client_ip) 的命令将 ip 和 keyword 的联合解析为单纯的 ip。你还可以使用类型转换语法 EVAL client_ip = client_ip::IP。或者，查询可以使用 TO_STRING 将所有支持的类型转换为 KEYWORD。

例如，返回带有 null 值的 client_ip:unsupported 的 查询 可以使用 TO_IP 函数或等效的 field::ip 语法进行改进。这些更改还解决了错误消息。只要对原始字段的唯一引用是将其传递给解决类型歧义的转换函数，就不会产生错误。

FROM events_*
| EVAL client_ip = TO_IP(client_ip)
| KEEP @timestamp, client_ip, event_duration, message
| SORT @timestamp DESC
		

当不同索引中 ES|QL 字段的类型是 date 和 date_nanos 的联合时，ES|QL 会在查询执行期间自动将所有值转换为 date_nanos 类型。这种隐式转换确保了所有值都以纳秒精度进行处理，无论其原始类型如何。因此，用户无需进行显式类型转换即可针对此类字段编写查询，查询引擎会无缝对齐类型以获得一致且精确的结果。

与 date 字段相比，date_nanos 字段提供更高的精度，但有效值范围更窄。这将其可表示的日期限制在大约 1970 年到 2262 年之间。这是因为日期存储为表示自纪元（epoch）以来的纳秒数的 long 值。当一个字段在不同索引中分别被映射为 date 和 date_nanos 时，ES|QL 默认使用精度更高的 date_nanos 类型。此行为确保在查询具有不同日期字段类型的多个索引时不会丢失精度。对于在不同索引中同时映射为 date 和 date_nanos 的字段中超出 date_nanos 有效范围的日期，ES|QL 默认返回 null。但是，用户可以显式将这些字段转换为 date 类型以获取有效值，精度限制为毫秒。

例如，如果 @timestamp 字段在一个索引中映射为 date，而在另一个索引中映射为 date_nanos，则 ES|QL 会在查询执行期间自动将所有 @timestamp 值视为 date_nanos。这允许用户编写使用 @timestamp 字段的查询而不会遇到类型不匹配错误，从而确保跨组合数据集的准确基于时间的运算和比较。

index: events_date

{
  "mappings": {
    "properties": {
      "@timestamp":     { "type": "date" },
      "client_ip":      { "type": "ip" },
      "event_duration": { "type": "long" },
      "message":        { "type": "keyword" }
    }
  }
}
		

index: events_date_nanos

{
  "mappings": {
    "properties": {
      "@timestamp":     { "type": "date_nanos" },
      "client_ip":      { "type": "ip" },
      "event_duration": { "type": "long" },
      "message":        { "type": "keyword" }
    }
  }
}
		

FROM events_date*
| EVAL date = @timestamp::date
| KEEP @timestamp, date, client_ip, event_duration, message
| SORT date
		

了解每行数据源自哪个特定的索引可能会很有用。要获取此信息，请在 FROM 命令上使用 METADATA 选项。

FROM events_* METADATA _index
| EVAL client_ip = TO_IP(client_ip)
| KEEP _index, @timestamp, client_ip, event_duration, message
| SORT @timestamp DESC
		

请注意，如果索引模式是 子查询 或 视图，则 _METADATA _index 将返回 null。