33

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

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

  • Вы все были правы. Я был немного смущен: | Том Кайт ответил на мой вопрос. Я разместил ответ Тома в верхней части моего ответа. Но я не хочу удалять свой первоначальный ответ ради истории. Поэтому я тоже оставил это здесь с заголовком «Неправильный ответ». Может быть, моя ошибка когда-нибудь кому-нибудь поможет.

    от
  • Можете ли вы указать на документацию в документации Oracle или Postgres, в которой указано, что порядок выбора определяется для этих типов хранения даже в отсутствиеORDER BY статья? Я уверен, что такого обещания не существует.

    от
  • Также я спросил об этой проблеме Тома Кайта в Твиттере, надеюсь, что он отправит ответ, а после того, как я опубликую ссылку на него.

    от
  • Не забывайте о вторичных индексах. Существует более одного способа доступа к IOT.

    от
  • @SingleNegationElimination Я разместил цитату из документов оракула. Жаль, что мой ответ отклонен ...

    от
  • Да, на это можно положиться. На него можно положиться, чтобы он не работал так, как вы полагали, что он работал ранее в самое неподходящее время :-)

    от DCookie
  • Если вы знаете порядок, который вы хотите, и ожидаете, то какой смысл пропуститьORDER BY? Стоит ли тратить эти клавиши на предсказуемость?

    от Aaron Bertrand
  • Нет, на это нельзя полагаться. В SQL Server, если вы не указали порядок, вы можете получить, например, сканирование по индексу или сканирование по назначению. Кроме того, вы также можете столкнуться с «расширенным сканированием». / Сканирование карусели.

    от Martin Smith
  • Добавьте предложение ORDER BY. Конец истории.

    от Remus Rusanu
  • 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 поля, которые вы действительно не считаете нужными, просто чтобы получить предсказуемый результат.

  • 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

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

  • 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 а затем тщательно настройте ваш запрос и базу данных, чтобы он был эффективным.

  • 4

    Том Кайт имеет

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