Являются ли поиск по столбцам IDENTITY более быстрым, если адресное пространство непрерывно?

Question

Если у меня очень большая таблица со столбцом IDENTITY (bigint) и эта таблица подлежит удалению, приведет ли фрагментация адресного пространства (доступные идентификаторы) к медленному SELECTS?

---

Пояснение:

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

Answer 1

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

Предполагается, что ваш столбец проиндексирован - SQL Server хранит индексы в b-дереве. Узлы этого дерева имеют оптимальный размер для системы подкачки системы. Поиск в узле будет определять правильные страницы дочерних узлов независимо от фрагментации индексов. Поскольку время, необходимое для загрузки страниц, будет меньше времени, необходимого для поиска по узлам, я не думаю, что фрагментация повлияет на время поиска.

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

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

Answer 2

номер

Если это не столбец индекса, фрагментация определенно не имеет значения, потому что в любом случае движок выполняет сканирование таблицы. (В зависимости от фактического запроса / объединения механизм не обязательно выполняет сканирование таблицы, но с точки зрения самого столбца, механизм не может сделать ничего лучше, кроме сканирования таблицы)

Если это индексированный столбец, индекс сохраняется в древовидной структуре, которая расширяется или сокращается во время вставки или удаления данных. Для этой древовидной структуры необходимо знать, что она «фрагментирована», даже если вы вставляете данные последовательно. Фрагментация здесь не в смысле единицы размещения диска, но каждый узел в дереве не полностью используется для диапазона данных, который он охватывает. Предполагаемая фрагментация состоит в том, чтобы избежать слишком частой реструктуризации деревьев. Движок использует коэффициент занятости, когда он реструктурирует дерево индексов (которое можно указать при создании индекса). Таким образом, независимо от того, является ли идентификатор непрерывным или нет, он хранится в большем пространстве памяти с некоторыми «пробелами» в нем. Удаление столбца не должно создавать заметных различий в производительности.

Тем не менее, база данных также выделяет место для хранения по страницам, что означает фрагментацию и связанную с этим проблему производительности. Но на ваш вопрос, это не имеет ничего общего с удалением в столбце id.

Answer 3

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

У вас все еще должен быть план обслуживания, который устраняет любую фрагментацию, особенно если вы делаете много удалений. Я должен признать, что это не моя сильная сторона, поэтому я не знаю, может ли SQL 2008 и / или ваш носитель данных сделать это ненужным.