Вопрос по sql-server – Порядок оператора SQL Select без предложения Order By

33

Как я знаю, из теории реляционных баз данныхselect заявление безorder by пункт должен рассматриваться не имеет определенного порядка. Но на самом деле в SQL Server и Oracle (я тестировал на этих двух платформах), если я запрашиваю из таблицы безorder by предложение несколько раз, я всегда получаю результаты в том же порядке. Можно ли положиться на это поведение? Кто-нибудь может помочь немного объяснить?

Добавьте предложение ORDER BY. Конец истории. Remus Rusanu
Нет, на это нельзя полагаться. В SQL Server, если вы не указали порядок, вы можете получить, например, сканирование по индексу или сканирование по назначению. Кроме того, вы также можете столкнуться с «расширенным сканированием». / Сканирование карусели. Martin Smith
Если вы знаете порядок, который вы хотите, и ожидаете, то какой смысл пропуститьORDER BY? Стоит ли тратить эти клавиши на предсказуемость? Aaron Bertrand
Да, на это можно положиться. На него можно положиться, чтобы он не работал так, как вы полагали, что он работал ранее в самое неподходящее время :-) DCookie

Ваш Ответ

4   ответа
4

Том Кайт имеетлюбимая мозоль об этой теме, По какой-то причине люди очарованы этим и продолжают пытаться придумывать случаи, когда вы можете положиться на конкретный заказ, не указывая ORDER BY. Как уже говорили другие, вы не можете. Здесь & APOS; sеще одна забавная тема по теме на сайте AskTom.

6

No, you can't rely on getting the results back in the same order every time. Я обнаружил это при работе с веб-страницей с постраничной сеткой. Когда я перешел на следующую страницу, а затем вернулся на предыдущую, на предыдущей странице были разные записи! Я был полностью озадачен.

For predictable results, then, you should include an ORDER BY. Даже тогда, если в указанных столбцах есть одинаковые значения, вы можете получить разные результаты. Возможно, вам придетсяORDER BY поля, которые вы действительно не считаете нужными, просто чтобы получить предсказуемый результат.

37

Нет, на это поведение нельзя положиться. Порядок определяется тем, как планировщик запросов решил создать набор результатов. простые запросы, такие какselect * from foo_table могут быть возвращены в том порядке, в котором они хранятся на диске, что может быть в порядке первичного ключа, или в порядке их создания, или в каком-то другом случайном порядке. более сложные запросы, такие какselect * from foo where bar < 10 вместо этого может быть возвращен в порядке другого столбца, на основе чтения индекса или порядка таблицы, для сканирования таблицы. еще более сложные запросы, с несколькимиwhere условия,group by статьи,unions, будет в любом порядке, который планировщик решит, будет наиболее эффективным для генерации.

Порядок может даже измениться между двумя одинаковыми запросами только из-за данных, которые изменились между этими запросами. «где» Предложение может быть удовлетворено сканированием индекса в одном запросе, но последующие вставки могут сделать это условие менее избирательным, и планировщик может принять решение выполнить последующий запрос, используя сканирование таблицы.


Чтобы сделать это более тонким. Системы СУБД имеют полномочия дать вамexactly то, что вы просили, максимально эффективно. Эта эффективность может принимать разные формы, включая минимизацию ввода-вывода (как на диск, так и по сети для отправки вам данных), минимизацию ЦП и сохранение небольшого размера рабочего набора (используя методы, требующие минимального временного хранения).

безORDER BY оговорка, вы не спросилиexactly для определенного порядка, и поэтому СУБД предоставит вам эти строки в некотором порядке, который (возможно) соответствует некоторому совпадению аспекта запроса, основываясь на том алгоритме, который СУБД ожидает получить данные быстрее.

Если вы заботитесь об эффективности, но не о порядке, пропуститеORDER BY пункт. Если вы заботитесь о заказе, но не об эффективности, используйтеORDER BY пункт.

Так как вы на самом деле заботитесь оBOTH использованиеORDER BY а затем тщательно настройте ваш запрос и базу данных, чтобы он был эффективным.

1

The Right Answer

Это новый ответ, добавленный для исправления старого. Я получил ответ от Тома Кайта и публикую его здесь:

If you want rows sorted YOU HAVE TO USE AN ORDER. No if, and, or buts about it. period. http://tkyte.blogspot.ru/2005/08/order-in-court.html You need order by on that IOT. Rows are sorted in leaf blocks, but leaf blocks are not stored sorted. fast full scan=unsorted rows.

https://twitter.com/oracleasktom/status/625318150590980097

https://twitter.com/oracleasktom/status/625316875338149888


The Wrong Answer

(Attention! The original answer on the question was placed below here only for the sake of the history. It's wrong answer. The right answer is placed above)

Как писал Том Кайт в статье, упомянутой ранее:

You should think of a heap organized table as a big unordered collection of rows. These rows will come out in a seemingly random order, and depending on other options being used (parallel query, different optimizer modes and so on), they may come out in a different order with the same query. Do not ever count on the order of rows from a query unless you have an ORDER BY statement on your query!

Но обратите внимание, он говорит только о таблицах, организованных в куче. Но есть и индексированные таблицы. В этом случае вы можете положиться на порядок выбора безORDER BY потому что порядок неявно определяется первичным ключом. Это верно для Oracle.

Для кластерных индексов SQL Server (организованных по индексу таблиц), созданных по умолчанию. Существует также возможность выравнивания информации в хранилище PostgreSQL по индексу. Больше информации можно найтиВот

UPDATE: Я вижу, что на мой ответ идет голосование вниз. Поэтому я постараюсь немного объяснить свою точку зрения. В разделеOverview of Index-Organized Tables есть фраза:

In an index-organized table, rows are stored in an index defined on the primary key for the table... Index-organized tables are useful when related pieces of data must be stored together or data must be physically stored in a specific order.

http://docs.oracle.com/cd/E25054_01/server.1111/e25789/indexiot.htm#CBBJEBIH

Из-за индексации все данные хранятся в определенном порядке, я считаю, что то же самое верно для Pg. http://www.postgresql.org/docs/9.2/static/sql-cluster.html

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

Также я спросил об этой проблеме Тома Кайта в Твиттере, надеюсь, что он отправит ответ, а после того, как я опубликую ссылку на него.
@SingleNegationElimination Я разместил цитату из документов оракула. Жаль, что мой ответ отклонен ...
Не забывайте о вторичных индексах. Существует более одного способа доступа к IOT.
Можете ли вы указать на документацию в документации Oracle или Postgres, в которой указано, что порядок выбора определяется для этих типов хранения даже в отсутствиеORDER BY статья? Я уверен, что такого обещания не существует.
Вы все были правы. Я был немного смущен: | Том Кайт ответил на мой вопрос. Я разместил ответ Тома в верхней части моего ответа. Но я не хочу удалять свой первоначальный ответ ради истории. Поэтому я тоже оставил это здесь с заголовком «Неправильный ответ». Может быть, моя ошибка когда-нибудь кому-нибудь поможет.

Похожие вопросы