Which statement is NOT true about a correlated subquery in SQL (that is, a subquery that references columns from its outer query)?

Introduction / Context:
A correlated subquery is evaluated once per candidate row of the outer query because it references outer columns inside the subquery. This behavior differs significantly from a non-correlated subquery, which the optimizer can often evaluate once and reuse. The question asks you to identify the statement that is not true of correlated subqueries.

Given Data / Assumptions:

• A correlated subquery contains predicates like t1.col > (SELECT AVG(x) FROM t2 WHERE t2.key = t1.key).
• EXISTS and NOT EXISTS commonly use correlated forms.
• We compare their behavior to regular (non-correlated) subqueries.

Concept / Approach:

Correlated subqueries run per outer row, creating a nested processing pattern. They are therefore not “very similar” to regular subqueries in evaluation strategy and performance characteristics. They can also be applied creatively to verify dependencies or constraints by checking that no outer row violates a rule when paired with related rows in the subquery.

Step-by-Step Solution:

Verification / Alternative check:

Inspect execution plans: correlated subqueries often appear as nested loops with a parameterized inner probe, unlike a single, reusable subplan of non-correlated subqueries.

Why Other Options Are Wrong:

EXISTS/NOT EXISTS: frequently correlated, true.

Nested processing: true by definition.

Verifying functional dependencies: feasible by checking rule violations per row, true in principle.

Common Pitfalls:

Ignoring performance implications of per-row subquery evaluation; forgetting that many correlated subqueries can be rewritten as joins or window functions for better performance.

Final Answer:

They are very similar to a regular subquery.