Является ли таблица внутренне отсортированной по ее первичному ключу? Если у меня есть таблица с первичным ключом в столбце идентификации BigInt, я могу доверять, что запросы всегда будут возвращать данные, отсортированные по ключу, или мне явно нужно добавить «ORDER BY». Разница в производительности значительна.Первичная сортировка ключей
Данные физически хранятся кластеризованным индексом, который обычно является первичным ключом, но необязательно.
Данные в SQL не гарантируются при заказе без предложения ORDER BY. Вы всегда должны указывать предложение ORDER BY, когда вам нужны данные в определенном порядке. Если таблица уже отсортирована таким образом, оптимизатор не будет выполнять какую-либо дополнительную работу, поэтому нет никакого вреда в ее наличии.
Без предложения ORDER BY RDBMS может возвращать кэшированные страницы, соответствующие вашему запросу, в то время как он ожидает записи записей с диска. В этом случае, даже если в таблице есть индекс, данные могут не войти в порядок индекса. (Обратите внимание, что это всего лишь пример - я не знаю, или даже думать о том, что в реальном мире СУБД будет делать это, но это приемлемое поведение для реализации SQL.)
EDIT
Если у вас есть влияние производительности при сортировке по сравнению с не сортировкой, вы, вероятно, сортируете по столбцу (или набору столбцов), который не имеет индекса (кластерного или другого). Учитывая, что это временный ряд, вы можете сортировать в зависимости от времени, но кластеризованный индекс находится на первичном bigint. SQL Server не знает, что оба увеличиваются одинаково, поэтому он должен прибегать ко всему.
Если столбец времени и столбец первичного ключа связаны друг с другом по порядку (один увеличивается тогда и только тогда, когда другой увеличивается или остается неизменным), сортируйте вместо этого первичный ключ. Если они не связаны таким образом, переместите кластеризованный индекс из первичного ключа в любой столбец (ы), который вы сортируете.
В SQL Server: нет, это ключ кластеризации - который по умолчанию используется для первичного ключа, но не обязательно должен быть одинаковым.
Основная функция первичного ключа состоит в том, чтобы однозначно идентифицировать каждую строку таблицы - но это не подразумевает никакой (физической) сортировки как таковой.
Не уверен, что касается других систем баз данных.
Марк
Это может быть конкретной реализации, но MySQL, кажется, сортировки по первичному ключу по умолчанию. Однако в любое время, когда вам нужна гарантия того, что строки будут упорядочены определенным образом, вы должны добавить ORDER BY.
, только если первичный ключ также является КЛАСТЕРНЫМ КЛЮЧОМ, который он по умолчанию, но не должен быть ....... –
Ах спасибо, что это хорошо знать. –
Таблица по умолчанию не является «кластеризованной», т. Е. Организована ПК. У вас есть возможность указать его как таковой. Таким образом, по умолчанию используется «HEAP» (в определенном порядке), а параметр, который вы ищете, - «CLUSTERED» (SQL Server, в Oracle - его имя IOT).
Более ранний плакат соответствует правилу, SQL (и теоретическая основа) определяет выберите как неупорядоченный набор/кортеж.
SQL обычно пытается остаться в логической области и не делать предположений о физической организации/местоположениях и т. Д. Данных. Опция CLUSTERED позволяет нам делать это для практических ситуаций в реальной жизни.
Почти каждый раз он будет сортировать по столам Identity. Он сортирует по кластерному индексу как и не всегда может быть отсортирован по идентификатору, но я никогда не видел, чтобы он не сортировал идентификатор идентификатора при выборе *. В чем причина не указания порядка? Я не понимаю, почему это вызывает разницу в производительности.
Причина в чисто производительности (см. Комментарий выше). – 2009-07-10 16:08:52
Без явного ORDER BY не существует порядка сортировки по умолчанию. Очень распространенный вопрос. Таким образом, есть консервированный ответ: «Разница в производительности значительна»
Without ORDER BY, there is no default sort order.
Вы можете уточнить, почему?
Данные представляют собой временные ряды, и запросы возвращают данные за месяц. Без заказа. Хранимая процедура может начать возвращать строки за считанные секунды. При заказе на минуту до первой строки возвращается. – 2009-07-10 16:07:24
Вы можете опробовать OPTION (FAST 1) http://msdn.microsoft.com/en-us/library/ms181714.aspx –
Чтобы гарантировать заказ, вы должны применить ORDER BY. Если вы заметили разницу в производительности, то, скорее всего, ваши данные не были отсортированы без ORDER BY на месте —, иначе SQL-Server должен вести себя плохо, так как он не понимает, что данные уже отсортированы. Добавление ORDER BY на уже отсортированные данные не должно нести штраф за производительность, поскольку РСУБД должна быть достаточно умна, чтобы реализовать порядок данных.
Первый абзац должен гласить: «Данные физически хранятся кластеризованным индексом ...». Все остальное, что говорит Welbog, - только потому, что оно физически хранится [в каждой странице] в порядке, не означает, что вы вернете его в этом порядке. Фрагментация физического диска также может повлиять на это. –
@Philip Kelley: Изменено, чтобы отразить вашу лучшую формулировку. Благодарю. – Welbog
Я фактически сортирую по Первичному ключу (который является BigInt). Данные были вставлены упорядоченным способом (по дате). – 2009-07-10 16:40:14