Modern SQL provides three powerful mechanisms to structure, modularize, and encapsulate queries: Subqueries (Derived Tables), Common Table Expressions (CTEs), and Database Views.
Junior developers often struggle to decide which tool to choose for a given task. Selecting the appropriate abstraction directly influences query readability, performance, cacheability, and security.
Architectural Feature Comparison
Feature / Dimension
Subquery (Derived Table)
CTE (WITH)
Database View
Persistence
Volatile (inline in query)
Volatile (single statement)
Persistent (stored DDL in data dictionary)
Reusability
Zero (must be retyped)
Reusable within same query
Globally reusable across all sessions/queries
Syntax Location
Embedded inside FROM/WHERE
Defined at top before main query
Created once via CREATE VIEW
Recursion Support
No
Yes (WITH RECURSIVE)
No (unless view queries a recursive CTE)
Security & Masking
No
No
Yes (Grant access to view, not base table)
Readability
Poor when nested deeply
Exceptional (top-down pipeline)
High (masks query completely)
Parameter Passing
N/A
N/A
N/A (requires filtering in outer WHERE)
When to Use Each Technique
1. When to Use a Database View
You need to share a standardized business calculation across multiple microservices or business intelligence dashboards (e.g., v_monthly_active_users).
You must restrict column-level or row-level access for security compliance (e.g., masking credit cards or employee salaries).
You want to decouple database schema changes from consumer applications.
2. When to Use a Common Table Expression (CTE)
You are constructing a complex multi-step data transformation or analytical report within a single query.
You need to reference the same intermediate aggregated dataset more than once in the same query.
You need to traverse hierarchical data structures, graphs, or sequences recursively.
You want clean, self-documenting, maintainable code without polluting the database catalog with permanent view objects.
3. When to Use an Inline Subquery
Quick, one-off comparisons in a WHERE clause (e.g., WHERE salary > (SELECT AVG(salary) FROM employees)).
Simple membership lookups with IN or existence checks with EXISTS.
Trivially simple derived tables that do not warrant the formality of a WITH block.
Performance Considerations in MySQL 8.0
In early versions of MySQL, derived tables always materialized temporary tables on disk. In modern MySQL 8.0+:
The query optimizer employs Derived Table Merging and CTE Inlining: simple CTEs and derived tables are rewritten into the parent query, allowing indexes from the underlying tables to be utilized.
If a CTE is referenced multiple times, MySQL can choose between materializing the CTE once into a temporary table or computing it in-place depending on cost estimation.
Views defined with ALGORITHM = MERGE incur zero performance penalty compared to raw table queries.
Interactive Quiz• Knowledge Check
Multiple Choice Questions
Question 1
Which abstraction is permanently stored in the database catalog and can be reused by multiple users across different sessions?
Question 2
If you need to traverse an organizational reporting tree recursively, which tool should you choose?
Question 3
If an analytics query needs to reference an intermediate aggregation three times in the same statement without polluting the schema with a permanent object, what is the best choice?
Question 4
For masking sensitive columns from an external reporting tool, which mechanism is required?
Question 5
Does a CTE persist on disk after the SQL query finishes executing?
Next Lesson
Window Functions Introduction vs GROUP BY
Continue learning with hands-on practice, examples, and exercises in the upcoming topic.