Documentation

Subqueries

Limited availability

InfluxDB Clustered is currently only available to a limited group of InfluxData customers. If interested in being part of the limited access group, please contact the InfluxData Sales team.

Subqueries (also known as inner queries or nested queries) are queries within a query. Subqueries can be used in SELECT, FROM, WHERE, and HAVING clauses.

Sample data

Query examples on this page use the following sample data sets:

Subquery operators

[ NOT ] EXISTS

The EXISTS operator returns all rows where a correlated subquery produces one or more matches for that row. NOT EXISTS returns all rows where a correlated subquery produces zero matches for that row. Only correlated subqueries are supported.

Syntax

[NOT] EXISTS (subquery)

[ NOT ] IN

The IN operator returns all rows where a given expression’s value can be found in the results of a correlated subquery. NOT IN returns all rows where a given expression’s value cannot be found in the results of a subquery or list of values.

Syntax

expression [NOT] IN (subquery|list-literal)

Examples

View IN examples using a query

View IN examples using a list literal

SELECT clause subqueries

SELECT clause subqueries use values returned from the inner query as part of the outer query’s SELECT list. The SELECT clause only supports scalar subqueries that return a single value per execution of the inner query. The returned value can be unique per row.

Syntax

SELECT [expression1[, expression2, ..., expressionN],] (<subquery>)

SELECT clause subqueries can be used as an alternative to JOIN operations.

Examples

SELECT clause with correlated subquery

FROM clause subqueries

FROM clause subqueries return a set of results that is then queried and operated on by the outer query.

Syntax

SELECT expression1[, expression2, ..., expressionN] FROM (<subquery>)

Examples

View FROM clause subquery example

WHERE clause subqueries

WHERE clause subqueries compare an expression to the result of the subquery and return true or false. Rows that evaluate to false or NULL are filtered from results. The WHERE clause supports correlated and non-correlated subqueries as well as scalar and non-scalar subqueries (depending on the the operator used in the predicate expression).

Syntax

SELECT
  expression1[, expression2, ..., expressionN]
FROM
  <measurement>
WHERE
  expression operator (<subquery>)

WHERE clause subqueries can be used as an alternative to JOIN operations.

Examples

WHERE clause with scalar subquery

WHERE clause with non-scalar subquery

WHERE clause with correlated subquery

HAVING clause subqueries

HAVING clause subqueries compare an expression that uses aggregate values returned by aggregate functions in the SELECT clause to the result of the subquery and return true or false. Rows that evaluate to false or NULL are filtered from results. The HAVING clause supports correlated and non-correlated subqueries as well as scalar and non-scalar subqueries (depending on the the operator used in the predicate expression).

Syntax

SELECT
  aggregate_expression1[, aggregate_expression2, ..., aggregate_expressionN]
FROM
  <measurement>
WHERE
  <conditional_expression>
GROUP BY
  column_expression1[, column_expression2, ..., column_expressionN]
HAVING
  expression operator (<subquery>)

Examples

HAVING clause with scalar subquery

HAVING clause with non-scalar subquery

HAVING clause with correlated subquery

Subquery categories

SQL subqueries can be categorized as one or more of the following based on the behavior of the subquery:

Correlated subqueries

In a correlated subquery, the inner query depends on the outer query, using values from the outer query for its results. Correlated subqueries can return a maximum of one row, so aggregations may be required in the inner query.

In the query below, the inner query (SELECT temp_avg FROM weather WHERE location = home.room) depends on data (home.room) from the outer query (SELECT time, room, temp FROM home) and is therefore a correlated subquery.

SELECT
  time,
  room,
  temp
FROM
  home
WHERE
  temp = (
    SELECT
      temp_avg
    FROM
      weather
    WHERE
      location = home.room
  )

Correlated subquery performance

Because correlated subqueries depend on the outer query and typically must execute for each row returned by the outer query, correlated subqueries are less performant than non-correlated subqueries.

Non-correlated subqueries

In a non-correlated subquery, the inner query doesn’t depend on the outer query and executes independently. The inner query executes first, and then passes the results to the outer query.

In the query below, the inner query (SELECT MIN(temp_avg) FROM weather) can run independently from the outer query (SELECT time, temp FROM home) and is therefore a non-correlated subquery.

SELECT
  time,
  temp
FROM
  home
WHERE
  temp < (
    SELECT
      MIN(temp_avg)
    FROM
      weather
  )

Scalar subqueries

A scalar subquery returns a single value (one column of one row). If no rows are returned, the subquery returns NULL.

The example subquery below returns the average value of a specified column. This value is a single scalar value.

SELECT * FROM home WHERE co > (SELECT avg(co) FROM home)

Non-scalar subqueries

A non-scalar subquery returns 0, 1, or multiple rows, each of which may contain 1 or multiple columns. For each column, if there is no value to return, the subquery returns NULL. If no rows qualify to be returned, the subquery returns 0 rows.

The example subquery below returns all distinct values in a column. Multiple values are returned.

SELECT * FROM home WHERE room IN (SELECT DISTINCT room FROM home_actions)

Was this page helpful?

Thank you for your feedback!


The future of Flux

Flux is going into maintenance mode. You can continue using it as you currently are without any changes to your code.

Flux is going into maintenance mode and will not be supported in InfluxDB 3.0. This was a decision based on the broad demand for SQL and the continued growth and adoption of InfluxQL. We are continuing to support Flux for users in 1.x and 2.x so you can continue using it with no changes to your code. If you are interested in transitioning to InfluxDB 3.0 and want to future-proof your code, we suggest using InfluxQL.

For information about the future of Flux, see the following: