Usually, sorting requires an extra step to put the data into the right
order. This extra step can be avoided for data that are already in the right
order. For example, if a single-table query has an ORDER BY on a single column,
and there is an index on that column, sorting can be avoided if uses
the index as the access path.
Where possible, 's query compiler transforms an SQL statement
internally into one that avoids this extra step. For information about internal
transformations, see . This
transformation, if it occurs, happens before optimization. After any such
transformations are made, the optimizer can do its part to help avoid a separate
sorting step by choosing an already sorted access path. It compares the cost
of using that path with the cost of sorting. does this for statements
that use an ORDER BY clause in the following situations:
- The statements involve tables with indexes that are in the correct order.
- The statements involve scans of unique indexes that are guaranteed to
return only one row per scan.
ORDER BY specifies a priority of ordering of columns in a result set. For
example, ORDER BY X, Y means that column X has a more
significant ordering than column Y.
The situations that allow to avoid a separate
ordering step for statements with ORDER BY clauses are:
- Index scans, which provide the correct order.
-- covering index
SELECT flight_id FROM Flights ORDER BY flight_id
- The rows from a table when fetched through an index scan.
-- if uses the index on orig_airport
-- to access the data, it can avoid the sort
-- required by the final ORDER BY
SELECT orig_airport, miles
FROM FLIGHTS
WHERE orig_airport < 'DDD'
ORDER BY orig_airport
- The rows from a join when ordered by the indexed column or columns in
the outer table.
-- if chooses Cities as the outer table, it
-- can avoid a separate sorting step
SELECT * FROM cities, countries
WHERE cities.country_ISO_code = countries.country_ISO_code
AND cities.country_ISO_code < 'DD'
ORDER BY cities.country_ISO_code
- Result sets that are guaranteed to return a single row. They are ordered
on all of their columns (for example, if there are
equality conditions on all the columns in a unique index, all the columns
returned for that table can be considered ordered, with any priority of ordering
of the columns).
-- query will only return one row, so that row is
-- "in order" for ANY column
SELECT miles
FROM Flights
WHERE flight_id = 'US1381' AND segment_number = 2
ORDER BY miles
- Any column in a result set that has an equality comparison with a constant.
The column is considered ordered with no priority to its ordering.
-- The comparison of segment_number
-- to a constant means that it is always correctly
-- ordered. Using the index on (flight_id, segment_number)
-- as the access path means
-- that the ordering will be correct for the ORDER BY
-- clause in this query. The same thing would be true if
-- flight_id were compared to a constant instead.
SELECT segment_number, flight_id
FROM Flights
WHERE segment_number=2
ORDER BY segment_number, flight_id
And because of transitive
closure, this means that even more complex statements can avoid sorting. For
example:
-- transitive closure means that will
-- add this clause:
-- AND countries.country_ISO_code = 'CL', which means
-- that the ordering column is now compared to a constant,
-- and sorting can be avoided.
SELECT * FROM cities, countries
WHERE cities.country_ISO_code = 'CL'
AND cities.country_ISO_code = countries.country_ISO_code
ORDER BY countries.country_ISO_code
For more information
about transitive closure and other statement transformations, see .