Чи дійсно можливо, що замовлення не буде гарантоване для цієї конкретної надлишкової похідної таблиці?

Я натрапив на це питання у розмові в Twitter із Лукашем Едером .

Хоча правильною поведінкою було б застосувати пункт ORDER BY до самого зовнішнього запиту, тому що тут ми не використовуємо DISTINCT, GROUP BY, JOIN або будь-який інший пункт WHERE у самому зовнішньому запиті, чому б RDBMS просто не передав пробіл вхідні дані, як це було відсортовано за внутрішнім запитом?

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)

Ось приклад із посібника з LUW DB2 (міна акценту)

Пункт 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 не порушать такої поведінки, щоб не зламати майже всю застарілу SQL SQL там, яка ще не перейшла на набагато бажаніші та читаний стандартний OFFSET .. FETCHсинтаксис SQL :

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

Так. Без ORDER BYпункту вихідний порядок не визначений, і планувальник запитів цілком відповідає своїй компетенції, припускаючи, що ви це знаєте і розумієте.

Він може вирішити, що оскільки зовнішній запит не визначає порядок, він може скидати впорядкування у внутрішній запит, щоб уникнути операції сортування, особливо якщо немає кластеризованого індексу або зовсім немає індексу для підтримки замовлення. Якщо цього немає зараз, це може зробити в майбутніх версіях.

Ніколи не покладайтеся на невизначену поведінку. Якщо вам потрібне конкретне замовлення, надайте ORDER BYпропозицію у відповідному місці.

Це сама проблема невизначеної поведінки - працює для вас, працює для мене, переформатує жорсткий диск у виробництві;)

Ми можемо зробити крок назад і сказати, що в одному сенсі ви маєте рацію - немає жодної земної причини, чому будь-яка розумна RDBMS переставляла б рядки у внутрішньому виділенні. Але це не гарантується - це означає, що в майбутньому може бути причина, і продавці можуть це зробити. Це означає, що будь-який код, який покладається на таку поведінку, знаходиться на користь змін, які постачальник може внести, які вони не підлягають жодному публічному оприлюдненню, оскільки це не є перехідною зміною від API POV.

Чи дійсно можливо, що замовлення не буде гарантоване для цієї конкретної надлишкової похідної таблиці?

Відповідь на всі існуючі на даний момент версії Postgres (які ви тестували): Ні - для цього конкретного запиту. Порядок сортування гарантований.

Людям SQL-сервера буде незручно з цим, оскільки Microsoft навіть не дозволяє ORDER BYв запитах. Порядок сортування гарантований для цього простого запиту в Postgres. ORDER BYзастосовується в підзапиті, і зовнішній запит не робить нічого, що може змінити порядок.

Посібник навіть так само натякає в главі Зведені функції :

Як альтернатива, подача вхідних значень із відсортованого підзапиту зазвичай працює.

Зауважте, це справедливо лише тоді, коли зовнішні рівні запитів не додають операцій, які можуть змінити порядок. Тож це "гарантовано" лише для простого випадку, і це не підкріплене стандартом SQL. Postgres вільний для повторного впорядкування, якщо він підходить для додаткових операцій. У разі сумнівів додайте ще одну ORDER BYдо зовнішньої SELECT. (У такому випадку внутрішній ORDER BYбуде надмірним шумом для цього простого запиту.)