- Yes it is.
- No, the query optimizer treats the whole query as one block. It doesn't run a derived table then run the outer statement on the result. It 'optimizes through' derived tables.
- Again, no. Having a derived table doesn't mean bad performance. You always have to look at your query as a whole.
- It's not a problem.
- Then that's just fine. Trust the query optimizer. Have you ever met the people that wrote it? They are scary intelligent.
In each individual case, it is worth looking at your query execution plan and finding pain points. Looks for things that are doing scans when they could be doing seeks, and that will usually give you a significant boost. Things do scans and not seeks when:
- There is no index to seek upon
- The thing you are seeking is the result of a function (e.g.
WHERE function(field) = value
) - The optimizer decides that a scan is actually faster.
But the bottom line answer to the question is - no, you should not be worried that derived tables would contain a lot of data if you selected them out in isolation.