Сортировка Первичных Ключей

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

7
indexing sql sql-server

7 ответов

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

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

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

редактировать

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

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

12

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

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

можете ли вы уточнить, почему " разница в производительности значительна."?

2

таблица по умолчанию не является "кластеризованной", т. е. организованной PK. У вас есть возможность указать его как таковой. Таким образом, по умолчанию используется "куча" (в определенном порядке), а параметр, который вы ищете, - "кластеризованный" (SQL Server, в Oracle его называют IOT).

  • таблица может иметь только один кластеризованный (имеет смысл)
  • используйте кластеризованный синтаксис первичного ключа в DDL
  • заказ ПК все еще должен быть выдан на ваш выбор, факт его наличия кластеризация приведет к ускорению выполнения запроса, так как план оптимизатора будет знать, что ему не нужно выполнять сортировку по кластеризованному индексу

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

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

1

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

1

в SQL Server: Нет, это кластеризации ключ - по умолчанию используется первичный ключ, но он не должен быть одинаковым.

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

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

Марк

0

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

0

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

0