Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

In which sequence are queries and sub-queries executed by the SQL engine?

Tags:

sql

subquery

Hello I made a SQL test and dubious/curious about one question:

In which sequence are queries and sub-queries executed by the SQL engine?

the answers was

  1. primary query -> sub query -> sub sub query and so on
  2. sub sub query -> sub query -> prime query
  3. the whole query is interpreted at one time
  4. There is no fixed sequence of interpretation, the query parser takes a decision on fly

I choosed the last answer (just supposing that it is most reliable w.r.t. others). Now the curiosity:

where can i read about this and briefly what is the mechanism under all of that?

Thank you.

like image 498
Igor Avatar asked Feb 14 '10 22:02

Igor


People also ask

Which sequence are queries and sub queries executed by SQL engine?

SQL executes innermost sub query first, and then the next level. The results of the sub query are the query conditions of the primary query. So in this case, the query sequence is sub query-> primary query, then the option b is the right answer.

What is the sequence of SQL query execution?

Six Operations to Order: SELECT, FROM, WHERE, GROUP BY, HAVING, and ORDER BY. By using examples, we will explain the execution order of the six most common operations or pieces in an SQL query. Because the database executes query components in a specific order, it's helpful for the developer to know this order.

Which is executed first query or subquery?

The sub-query always executes before the execution of the main query. Subqueries are completed first. The result of the subquery is used as input for the outer query.


1 Answers

I think answer 4 is correct. There are a few considerations:

type of subquery - is it corrrelated, or not. Consider:

SELECT * FROM   t1 WHERE  id IN (              SELECT id              FROM   t2             ) 

Here, the subquery is not correlated to the outer query. If the number of values in t2.id is small in comparison to t1.id, it is probably most efficient to first execute the subquery, and keep the result in memory, and then scan t1 or an index on t1.id, matching against the cached values.

But if the query is:

SELECT * FROM   t1 WHERE  id IN (              SELECT id              FROM   t2              WHERE  t2.type = t1.type             ) 

here the subquery is correlated - there is no way to compute the subquery unless t1.type is known. Since the value for t1.type may vary for each row of the outer query, this subquery could be executed once for each row of the outer query.

Then again, the RDBMS may be really smart and realize there are only a few possible values for t2.type. In that case, it may still use the approach used for the uncorrelated subquery if it can guess that the cost of executing the subquery once will be cheaper that doing it for each row.

like image 98
Roland Bouman Avatar answered Sep 16 '22 21:09

Roland Bouman