ДЕЙСТВИТЕЛЬНО ли возможно, что порядок для этой конкретной избыточной производной таблицы не будет гарантирован?

Я наткнулся на этот вопрос в беседе в Твиттере с Лукасом Эдером .

Хотя правильное поведение будет заключаться в применении предложения ORDER BY к самому внешнему запросу, поскольку здесь мы не используем DISTINCT, GROUP BY, JOIN или любое другое предложение WHERE в самом внешнем запросе, почему бы СУРБД просто не передать входящие данные как они были отсортированы по внутреннему запросу?

SELECT * 
FROM (
    SELECT * FROM table ORDER BY time DESC
) AS t

При запуске этого примера на PostgreSQL, по крайней мере, вы получаете один и тот же план выполнения как для внутреннего запроса, так и для этого примера производной таблицы, а также один и тот же набор результатов.

Итак, я предполагаю, что планировщик просто отбросит самый внешний запрос, потому что он избыточен, или просто пропустит результаты из внутренней таблицы.

Кто-нибудь думает, что это может быть не так?

Большинство баз данных совершенно ясно понимают, что ORDER BYподзапрос - это либо:

• Недопустимо: например, SQL Server, Sybase SQL Anywhere (если не дополнено TOPили OFFSET .. FETCH)
• Бессмысленно: например, PostgreSQL, DB2 (опять же, если не дополнено OFFSET .. FETCHили LIMIT)

Вот пример из руководства по DB2 LUW (выделено мое)

Предложение ORDER BY в подвыборке не влияет на порядок строк, возвращаемых запросом. Предложение ORDER BY влияет только на порядок возвращаемых строк, если оно указано во внешней полной выборке.

Формулировка довольно четкая, как и в PostgreSQL :

Если сортировка не выбрана, строки будут возвращены в неуказанном порядке. Фактический порядок в этом случае будет зависеть от типов планов сканирования и соединения и порядка на диске, но на него нельзя полагаться . Конкретный порядок вывода может быть гарантирован, только если шаг сортировки выбран явно.

Из этой спецификации следует, что любой порядок, полученный в результате ORDER BYпредложения в производной таблице, является просто случайным и может совпадать с вашим ожидаемым порядком (что он делает в большинстве баз данных в вашем тривиальном примере), но было бы неразумно полагаться на это.

Дополнительное примечание по DB2:

В частности, DB2 имеет менее известную функцию под названиемORDER BY ORDER OF <table-designator> , которая может использоваться следующим образом:

SELECT C1 FROM
   (SELECT C1 FROM T1
      UNION
    SELECT C1 FROM T2
    ORDER BY C1 ) AS UTABLE
ORDER BY ORDER OF UTABLE

В этом конкретном случае упорядочение производной таблицы может быть явно использовано повторно во внешнем SELECT

Дополнительное примечание по Oracle:

В течение многих лет в Oracle практикуется использование OFFSETразбиения на страницы ROWNUM, которое может быть разумно рассчитано только после заказа производной таблицы:

SELECT *
FROM (
  SELECT rownum AS rn, t.* -- ROWNUM here depends on the derived table's ordering
  FROM (
    SELECT * FROM table ORDER BY time DESC
  ) t
) t
WHERE rn BETWEEN 10 AND 20

Можно разумно ожидать, что, по крайней мере, при наличии ROWNUMв запросе будущие версии Oracle не будут нарушать это поведение, чтобы не сломать практически весь существующий Oracle SQL, который еще не перешел на гораздо более желательный и читаемый стандартный OFFSET .. FETCHсинтаксис SQL :

SELECT * FROM table ORDER BY time DESC OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY

Да. Без ORDER BYпредложения порядок вывода не определен, и планировщик запросов вполне может предположить, что вы это знаете и понимаете.

Он может решить, что, поскольку внешний запрос не определяет порядок, он может отбросить порядок во внутреннем запросе, чтобы избежать операции сортировки, особенно если нет кластерного индекса или индекса вообще, чтобы поддерживать порядок. Если этого не произойдет сейчас, это может быть сделано в будущих версиях.

Никогда не полагайтесь на неопределенное поведение. Если вам нужен конкретный заказ, дайте ORDER BYпункт в соответствующем месте.

Сама проблема с неопределенным поведением - работает для вас, работает для меня, переформатирует жесткий диск в prod;)

Мы можем сделать шаг назад и сказать, что в каком-то смысле вы правы - нет никаких земных причин, по которым любая здравомыслящая СУБД будет переставлять строки во внутреннем выборе. Но это не гарантировано - это означает, что в будущем может быть причина, и поставщики могут это сделать. Это означает, что любой код, основанный на этом поведении, зависит от изменений, которые может сделать поставщик, и которые он не обязан публиковать, поскольку это не является принципиальным изменением от API POV.

ДЕЙСТВИТЕЛЬНО ли возможно, что порядок для этой конкретной избыточной производной таблицы не будет гарантирован?

Ответ для всех существующих на данный момент версий Postgres (которые вы тестировали): Нет - для этого конкретного запроса. Порядок сортировки гарантирован.

Людям на SQL-сервере это будет неудобно, поскольку Microsoft даже не допускает ORDER BYподзапросов. Тем не менее, порядок сортировки для этого простого запроса в Postgres гарантирован. ORDER BYприменяется в подзапросе, и внешний запрос не делает ничего, что могло бы изменить порядок.

Руководство даже намекает так много в главе Агрегатные функции :

Альтернативно, подача входных значений из отсортированного подзапроса обычно работает.

Обратите внимание, что это верно только тогда, когда внешние уровни запросов не добавляют операции, которые могут изменить порядок. Так что это «гарантировано» только для простого случая, и это не поддерживается стандартом SQL. Postgres может изменить порядок, если он подходит для дополнительных операций. В случае сомнений добавьте еще один ORDER BYк внешнему SELECT. (В этом случае внутренняя часть ORDER BYбудет лишним шумом для этого простого запроса.)