Вопрос по sql-server, sql, indexing – Сортировка первичного ключа

7

Таблица отсортирована по первичному ключу? Если у меня есть таблица с первичным ключом в столбце идентификаторов BigInt, могу ли я верить, что запросы всегда будут возвращать данные, отсортированные по ключу, или мне явно нужно добавить & quot; ORDER BY & quot ;. Разница в производительности значительна.

Возможный дубликатDoes 'Select' always order by primary key? philipxy

Ваш Ответ

7   ответов
0

Он сортирует по кластерному индексу, и не всегда может быть отсортирован по идентификатору, но я никогда не видел, чтобы он не сортировался по идентификатору идентификатора при выборе *. В чем причина отсутствия указания заказа? Я не понимаю, почему это вызывает разницу в производительности.

Причина заключается исключительно в производительности (см. Комментарий выше).
12

который обычно является первичным ключом, но это не обязательно.

Данные в SQL не гарантированно имеют порядок без предложения ORDER BY. Вы всегда должны указывать предложение ORDER BY, когда вам нужно, чтобы данные были в определенном порядке. Если таблица уже отсортирована таким образом, оптимизатор не будет выполнять какую-либо дополнительную работу, поэтому ее не будет вредно.

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

EDIT

Если вы оказываете влияние на производительность при сортировке, а не при сортировке, вы, вероятно, сортируете по столбцу (или набору столбцов), который не имеет индекса (кластеризованного или иного). Учитывая, что это временные ряды, вы можете сортировать по времени, но кластерный индекс находится на первичном значении. SQL Server не знает, что оба увеличиваются одинаково, поэтому ему приходится прибегать ко всему.

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

@Philip Kelley: изменен, чтобы отразить вашу лучшую формулировку. Благодарю.
Я на самом деле сортировка по первичному ключу (который является BigInt). Данные были вставлены упорядоченным способом (по дате).
Является ли первичный ключ кластеризованным индексом?
Первичный ключ кластеризован, а ключом является поле ID (BigInt).
В первом абзаце должно быть сказано: «Данные физически хранятся в кластерном индексе ...». Все остальное, что говорит Welbog, применимо - просто потому, что оно физически хранится [на каждой странице] в порядке, не означает, что вы получите его обратно в таком порядке. Фрагментация физического диска также может оказать влияние на это.
0

clustering key - который по умолчанию равен первичному ключу, но не должен быть таким же.

Основной функцией первичного ключа является уникальная идентификация каждой строки в таблице, но она не предполагает какой-либо (физической) сортировки как таковой.

Не уверен насчет других систем баз данных.

Марк

1

. У вас есть возможность указать его как таковой. Поэтому по умолчанию используется значение «HEAP». (в произвольном порядке), и параметр, который вы ищете, является & quot; CLUSTERED & quot; (SQL Server, в Oracle его называют IOT).

A table can only have one CLUSTERED (makes sense) Use the PRIMARY KEY CLUSTERED syntax on the DDL Order by PK still needs to be issued on your SELECTS, the fact of it being clustered will cause the query to run faster, as the optimizer plan will know it does not need to do the sorting on a clustered index

Предыдущий плакат верен, SQL (и его теоретическая основа) определенно определяет выбор как неупорядоченный набор / кортеж.

SQL обычно пытается оставаться в логической сфере и не делать предположений о физической организации / расположении и т. Д. Данных. Опция CLUSTERED позволяет нам делать это в реальных жизненных ситуациях.

1

ORDER BY гарантировать заказ. Если вы заметили разницу в производительности, скорее всего, ваши данные не были отсортированы безORDER BY на месте & # x2014; в противном случае SQL-сервер должен вести себя плохо, так как он не понимает, что данные уже отсортированы. ДобавлениеORDER BY для уже отсортированных данных не следует снижать производительность, поскольку СУБД должна быть достаточно умной, чтобы реализовать порядок данных.

0

но MySQL, кажется, сортирует по первичному ключу по умолчанию. Однако всякий раз, когда вам требуется гарантия того, что строки будут упорядочены определенным образом, вы должны добавить ORDER BY.

Ах, спасибо, что это хорошо знать.
только если первичный ключ также является КЛАСТЕРИЧЕСКИМ КЛЮЧОМ - который он является по умолчанию, но не ДОЛЖЕН быть .......
2

нь распространенный вопрос. Таким образом, существует законный ответ:

Без ORDER BY порядок сортировки по умолчанию отсутствует.

Не могли бы вы пояснить, почему & quot; Разница в производительности значительна. & Quot ;?

Вы можете попробовать ВАРИАНТ (БЫСТРО 1)msdn.microsoft.com/en-us/library/ms181714.aspx
Данные представляют собой временные ряды, и запросы возвращают данные за месяцы. Без заказа По хранимой процедуре можно начать возвращать строки в течение нескольких секунд С Order By до первого ряда возвращается не более минуты.

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