Home/ Questions/Q 8156029
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T16:49:56+00:00

Recently, I came across a pattern (not sure, could be an anti-pattern) of sorting

  • 0

Recently, I came across a pattern (not sure, could be an anti-pattern) of sorting data in a SELECT query. The pattern is more of a verbose and non-declarative way for ordering data. The pattern is to dump relevant data from actual table into temporary table and then apply orderby on a field on the temporary table. I guess, the only reason why someone would do that is to improve the performance (which I doubt) and no other benefit.

For e.g. Let’s say, there is a user table. The table might contain rows in millions. We want to retrieve all the users whose first name starts with ‘G’ and sorted by first name. The natural and more declarative way to implement a SQL query for this scenario is:

More natural and declarative way

SELECT * FROM Users
WHERE NAME LIKE 'G%'
ORDER BY Name

Verbose way

SELECT * INTO TempTable
FROM Users
WHERE NAME LIKE 'G%'

SELECT * FROM TempTable
ORDER BY Name

With that context, I have few questions:

  1. Will there be any performance difference between two ways if there is no index on the first name field. If yes, which one would be better.

  2. Will there be any performance difference between two ways if there is an index on the first name field. If yes, which one would be better.

  3. Should not the SQL Server optimizer generate same execution plan for both the ways?

  4. Is there any benefit in writing a verbose way from any other persective like locking/blocking?

Thanks in advance.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Reguzlarly: Anti pattern by people without an idea what they do.

    SOMETIMES: ok, because SQL Server has a problem that is not resolvable otherwise – not seen that one in yeas, though.

    It makes things slower because it forces the tmpddb table to be fully populated FIRST, while otherwise the query could POSSIBLY be resoled more efficiently.

    last time I saw that was like 3 years ago. We got it 3 times as fast by not being smart and using a tempdb table 😉

    Answers:

    1: No, it still needs a table scan, obviously.

    2: Possibly – depends on data amount, but an index seek by index would contain the data in order already (as the index is ordered by content).

    3: no. Obviously. Query plan optimization is statement by statement. By cutting the execution in 2, the query optimizer CAN NOT merge the join into the first statement.

    4: Only if you run into a query optimizer issue or a limitation of how many tables you can join – not in that degenerate case (degenerate in a technical meaning – i.e. very simplistic). BUt if you need to join MANY MANY tables it may be better to go with an interim step.

    • 0