Introduction

“Multiple SELECT statements in one query” can mean two different things. You might mean combining several result sets into one logical query, or you might mean sending several semicolon-separated statements to the database in one round trip. Those are different techniques and they have different tradeoffs.

Combine Results with UNION or UNION ALL

If the goal is one result set assembled from several SELECT statements, UNION ALL is usually the clearest tool.

1SELECT id, name, 'customer' AS source
2FROM customers
3UNION ALL
4SELECT id, name, 'supplier' AS source
5FROM suppliers;

Use UNION only when you specifically want duplicate elimination. UNION ALL is usually faster because it does not need the extra deduplication step.

Use Subqueries for One Statement That Depends on Another

If one selection feeds another, use a subquery or common table expression.

1SELECT name
2FROM employees
3WHERE department_id IN (
4    SELECT id
5    FROM departments
6    WHERE active = 1
7);

Or with a CTE:

1WITH active_departments AS (
2    SELECT id
3    FROM departments
4    WHERE active = 1
5)
6SELECT name
7FROM employees
8WHERE department_id IN (SELECT id FROM active_departments);

This is still one SQL statement, even though several SELECT clauses appear inside it.

Multiple Statements in One Round Trip

Some database drivers let you send several statements separated by semicolons:

SELECT COUNT(*) FROM orders;
SELECT COUNT(*) FROM customers;

Whether this works depends on the database, driver, and client configuration. Many application frameworks disable multi-statement execution because it complicates result handling and can increase SQL injection risk.

So if the real question is “can I send two independent SELECT statements in one call,” the answer is: sometimes, but it is driver-specific and often not the best design.

Prefer One Clear Result Shape

For application code, it is usually easier to consume one predictable result shape.

If you need related data together, joins are often better than separate SELECT statements:

SELECT o.id, o.total, c.name
FROM orders o
JOIN customers c ON c.id = o.customer_id;

If you truly need several independent aggregates, consider separate queries in the application layer unless latency makes batching necessary.

Choosing the Right Pattern

Use this rule of thumb:

• 'UNION ALL for stacking similar rows'
• subqueries or CTEs when one selection feeds another
• joins when you want related columns side by side
• multiple statements only when the driver and use case genuinely justify it

That framing is more useful than asking whether SQL “allows multiple SELECT statements,” because the right answer depends on the result shape you need.

Application Layer Versus SQL Layer

Sometimes two separate queries in the application are the cleanest option. If the results are unrelated, forcing them into one SQL statement can make the code harder to reason about. Optimize for round trips only when latency is actually the bottleneck.

Common Pitfalls

The first pitfall is using UNION when the two queries return different column counts or incompatible types.

Another mistake is assuming semicolon-separated statements are portable across drivers and ORMs. Many frameworks reject them.

A third issue is using multiple SELECT statements when a join or CTE would be simpler and easier to maintain.

Summary

• 'UNION ALL combines rows from multiple SELECT statements into one result set.'
• Subqueries and CTEs let one SELECT depend on another inside a single SQL statement.
• Semicolon-separated multi-statement execution is driver-specific and often restricted.
• Joins are usually better when you need related data in the same row.
• Choose the pattern based on the result shape you actually want.