Documentation

SELECT statement

Use the SELECT statement to query data from one or more measurements. The SELECT statement requires a SELECT clause and a FROM clause.

Syntax

SELECT field_expression[, ..., field_expression_n[, tag_expression[, ..., tag_expression_n]]] FROM measurement_expression[, ..., measurement_expression_n]

SELECT clause

The SELECT clause supports several formats for identifying data to query. It requires one or more field expressions and optional tag expressions.

  • field_expression: Expression to identify one or more fields to return in query results. Can be a field key, constant, regular expression, wildcard (*), or function expression and any combination of arithmetic operators.
  • tag_expression: Expression to identify one or more tags to return in query results. Can be a tag key or constant.

Select clause behaviors

  • SELECT field_key - Returns a specific field.
  • SELECT field_key1, field_key2 - Returns two specific fields.
  • SELECT field_key, tag_key - Returns a specific field and tag.
  • SELECT * - Returns all fields and tags. See Wildcard expressions.
  • SELECT /^[t]/ - Returns all fields and tags with keys that match the regular expression. At least one field key must match the regular expression. If no field keys match the regular expression, no results are returned.

FROM clause

The FROM clause specifies the measurement or subquery to query. It requires one or more comma-delimited measurement expressions or subqueries.

measurement_expression

A measurement expression identifies a measurement to query. It can be a measurement name, fully-qualified measurement, constant, or a regular expression.

  • Measurement name: When using just the measurement name, InfluxQL assumes the default retention policy of the database specified in the query request.

    FROM measurement
  • Fully-qualified measurement: A fully qualified measurement includes a database name, retention policy name, and measurement name, each separated by a period (.). If the retention policy is not specified, InfluxQL uses the default retention policy for the specified database.

FROM database.retention_policy.measurement

-- Fully-qualified measurement with default retention policy
FROM database..measurement

InfluxQL retention policies

In InfluxDB 3 Core, retention policies are not part of the data model like they are in InfluxDB 1.x. Each InfluxDB 3 Core database has a retention period which defines the maximum age of data to retain in the database. To use fully-qualified measurements in InfluxQL queries, use the following naming convention when creating a database:

database_name/retention_policy

Subquery

An InfluxQL subquery is a query nested in the FROM clause of an InfluxQL query. The outer query queries results returned by the inner query (subquery).

For more information, see InfluxQL subqueries.

Notable SELECT statement behaviors

Must query at least one field

A query requires at least one field key in the SELECT clause to return data. If the SELECT clause includes only tag keys, the query returns an empty result. When using regular expressions in the SELECT clause, if regular expression matches only tag keys and no field keys, the query returns an empty result.

To return data associated with tag keys, include at least one field key in the SELECT clause.

Wildcard expressions

When using a wildcard expression (*) in the SELECT clause, the query returns all tags and fields. If a function is applied to a wildcard expression, the query returns all fields with the function applied, but does not return tags unless they are included in the SELECT clause.

Cannot include both aggregate and non-aggregate field expressions

The SELECT statement cannot include an aggregate field expression (one that uses an aggregate or selector function) and a non-aggregate field expression. For example, in the following query, an aggregate function is applied to one field, but not the other:

SELECT mean(temp), hum FROM home

This query returns an error. For more information, see error about mixing aggregate and non-aggregate queries.

Data types and casting operations

The SELECT clause supports specifying a field’s type and basic casting operations with the :: syntax.

SELECT field_expression::type FROM measurement_expression

The :: syntax allows users to perform basic cast operations in queries. Currently, InfluxQL supports casting numeric field values to other numeric types. Casting to an identifier type acts as a filter on results and returns only columns of that specific identifier type along with the time column.

Numeric types
  • float
  • integer
  • unsigned
Non-numeric types
  • string
  • boolean
Identifier types
  • field
  • tag

InfluxQL returns no data if the query attempts to cast a numeric value to a non-numeric type and vice versa.

When casting a float value to an integer or unsigned integer, the float value is truncated at the decimal point. No rounding is performed.

SELECT statement examples

The examples below use the following sample data sets:

Select all fields and tags from a measurement

Select specific tags and fields from a measurement

Select all fields from a measurement

Select a field from a measurement and perform basic arithmetic

Select all data from more than one measurement

Select all data from a fully-qualified measurement (with default retention policy)

Type-casting examples

Cast an integer field to a float

Cast a float field to an integer

Cast a float field to an unsigned integer


Was this page helpful?

Thank you for your feedback!


InfluxDB OSS 2.9.0: API tokens are hashed by default

Stronger token security in InfluxDB OSS 2.9.0 — tokens are hashed on disk by default. Existing tokens are hashed on first startup and can’t be recovered afterward. Capture any plaintext tokens you still need before you upgrade.

View InfluxDB OSS 2.9.0 release notes

Hashed tokens authenticate exactly like unhashed tokens — clients and integrations keep working.

Also new in 2.9.0:

  • Configurable backup compression
  • Restore support for backups containing hashed tokens
  • Tighter Edge Data Replication queue validation
  • Flux upgrade
  • Compaction reliability improvements

Key enhancements in Explorer 1.9

Explorer 1.9 is now available with InfluxQL support, an AI-assisted Flux to SQL converter (beta), and new live sample data simulators.

View Explorer 1.9 release notes

Explorer 1.9 includes new features and improvements that make it easier to query, visualize, and manage data.

Highlights:

  • Flux to SQL converter (beta): Convert Flux queries to SQL with an AI-assisted converter.
  • InfluxQL support: Query data with InfluxQL in the Data Explorer and dashboards, and save and load InfluxQL queries.
  • InfluxQL visualizations: Render line and bar charts from InfluxQL results with per-tag series grouping.
  • Query error history: Review a history of query errors in the query tool.
  • Live sample data simulators: Generate continuous live sample data with new bird data and signal generator simulators.

For more details, see Explorer 1.9 release notes

InfluxDB 3.10 is now available

InfluxDB 3 Core 3.10 adds an automatic catalog format upgrade, a configurable query-concurrency limit, and processing engine improvements.

Key updates in InfluxDB 3 Core 3.10:

  • Catalog format upgrade: the on-disk catalog automatically upgrades from format v2 to v3 on first 3.10 startup. Migration is one-way—back up your catalog before upgrading.
  • --max-concurrent-queries: limit concurrent queries (adjustable at runtime).
  • GET /ready endpoint for readiness probes.
  • Processing engine: cross-database queries and trigger lockdown flags.

For more information, see the InfluxDB 3 Core release notes.

InfluxDB 3.10 is now available

InfluxDB 3 Enterprise 3.10 adds automated backup and restore, row-level deletions, and user management, with an automatic catalog format upgrade and performance preview improvements.

Key updates in InfluxDB 3 Enterprise 3.10:

  • Catalog format upgrade: the on-disk catalog automatically upgrades from format v2 to v3 on first 3.10 startup. Migration is one-way—back up your catalog before upgrading.
  • Automated backup and restore (beta)
  • Row-level deletions
  • User management (authentication and RBAC) — preview
  • Performance preview improvements

Backup and restore, row-level deletions, and the performance preview require the Enterprise storage engine upgrade (opt-in beta). Beta and preview features are subject to breaking changes and aren’t recommended for production use.

For more information, see the InfluxDB 3 Enterprise release notes

Telegraf Enterprise is now generally available

Telegraf Enterprise is now generally available, along with Telegraf Controller v1.0.

Telegraf Enterprise combines Telegraf Controller, a centralized management console for Telegraf, with official support from InfluxData. Manage configurations, monitor fleet health, and operate tens of thousands of Telegraf agents from a single system.

InfluxDB Docker latest tag changing to InfluxDB 3 Core

On September 15, 2026, the latest tag for InfluxDB Docker images will point to InfluxDB 3 Core. To avoid unexpected upgrades, use specific version tags in your Docker deployments.

If using Docker to install and run InfluxDB, the latest tag will point to InfluxDB 3 Core. To avoid unexpected upgrades, use specific version tags in your Docker deployments. For example, if using Docker to run InfluxDB v2, replace the latest version tag with a specific version tag in your Docker pull command–for example:

docker pull influxdb:2