A subquery lets you embed one SELECT statement inside another to filter, aggregate, or transform data before the outer query runs.
A subquery is a SELECT statement enclosed in parentheses and used as a source table for an outer query. It runs first, feeding its result set to the surrounding query.
Subqueries shine for quick, inline filtering or aggregations when you don’t need to reference the result more than once. They avoid naming overhead but can reduce readability compared to CTEs.
Place the inner SELECT inside parentheses in the FROM or WHERE clause. Alias it if used in FROM to expose its columns to the outer query.
Use a subquery in the WHERE clause with IN, EXISTS, or comparison operators to limit rows returned by the outer query.
Embed the subquery in the FROM clause and join it like a table. Always alias the subquery to reference its columns.
Wrap an aggregate subquery in the FROM clause, then apply additional aggregation or filtering in the outer query for multi-step analysis.
Alias clearly, keep inner result sets small, and avoid deeply nested subqueries. Convert complex, reusable logic to CTEs for clarity and performance.
Returning multiple columns in a scalar context or forgetting to alias subqueries in the FROM clause causes errors. Check that inner SELECT returns the expected shape.
Yes. Correlated subqueries reference columns from the outer query. BigQuery rewrites many correlated subqueries for efficiency, but ensure they return few rows per evaluation.
Not inherently. Performance depends on data scanned. Limit columns, filter early, and check query plan to avoid full-table scans inside subqueries.
If the inner result set is reused, complex, or hampers readability, use WITH (CTE) instead. CTEs can also improve optimizer hints and caching.