Производительность SQL Server и значения кластерного индекса

Question

У меня есть таблица myTable с уникальным кластеризованным индексом myId с коэффициентом заполнения 100% Его целое число, начиная с нуля (но это не столбец идентичности для таблицы) Мне нужно добавить новый тип строки к таблице. Возможно, было бы хорошо, если бы я мог отличить эти строки, используя отрицательные значения myId.

Имеет ли отрицательные значения дополнительные страницы, разделяющие и замедляющие вставки?

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

Резюме: Коэффициенты заполнения 100% будут норамли замедлять вставки. Но не вставки, которые происходят последовательно, и это включает в себя временные отрицательные вставки.

Answer 1

Помимо практических пунктов администрирования, которые вы уже получили, и подозрительное сомнительное использование отрицательных идентификаторов для представления атрибутов модели данных, здесь также имеется веский вопрос: дать таблицу с идентификаторами int от 0 до N, вставив новые отрицательные значения, будут ли эти ценности идти и будут ли они вызывать дополнительные расщепления?

Исходные строки будут размещены на листах страниц с кластеризованным индексом, строка с идентификатором 0 на первой странице и строка с идентификатором N на последней странице, заполняя страницы между ними. Когда вставлена ​​первая строка со значением -1, она будет сортировать опережающую строку с id 0 и, как таковая, добавит новую страницу в дерево (на самом деле будет выделять 8 страниц, но это другая точка) и свяжет страницу перед листом, связанным списком страниц. Это НЕ приведет к расколу страницы на первой странице. При последующих вставках значений -2, -3 и т. Д. Они перейдут на одну и ту же новую страницу, и они будут вставлены в правильное положение (-2 впереди -1, -3 впереди -2 и т. Д.), Пока страница не заполнится. Дальнейшие вставки добавят новую страницу вперед, которая будет соответствовать новым новым значениям. Вставки положительных значений N + 1, N + 2 будут отображаться на последней странице и помещаться в нее до тех пор, пока она не заполнится, затем они добавят новую страницу и начнут заполнять эту страницу.

Итак, в основном, ответ таков: вставки на любом конце кластерного индекса не должны вызывать разбиение страниц. Разбиение страницы может быть вызвано только вставками между двумя существующими ключами. Это фактически распространяется и на страницы, не связанные с листом, индекс на обоих концах кластера также не может разделить нестраничную страницу. Я не обсуждаю здесь влияние обновлений, конечно (они могут вызвать расщепления, если увеличить длину столбца переменной длины).

В последнее время было много разговоров в блогосфере SQL Server о потенциальных проблемах производительности разделов страниц, но я должен предостеречь от ненужных крайностей, чтобы избежать их. Разделение страниц - это нормальная операция индекса. Если вы окажетесь в среде, в которой поражение производительности разделяется на страницы во время вставок, вы, вероятно, будете хуже пострадать от мер «смягчения», потому что вы создадите искусственные горячие точки для защелок, которые намного хуже, чем они будут затрагивают каждый вставка. То, что - это, верно, что длительная работа с частыми расщеплениями приведет к высокой фрагментации, которая влияет на время доступа к данным. Я говорю, что лучше всего смягчить с помощью операции по обновлению периодических индексов (реорганизация). Избегайте преждевременных оптимизаций, всегда измерьте сначала.

Answer 2

Недостаточно отметить для любой разумной системы.

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

Edit, после того, как коэффициент заполнения комментариев:

После страницы разделения 90 или т-й 100 FF, каждая страница будет 50% от полной. FF = 100 означает, что вставка произойдет раньше (возможно, первая вставка).

С строго монотонно увеличивающейся (или уменьшающейся) клавишей (+ ve или -ve) разделение страницы происходит на обоих концах диапазона.

Однако из BOL, FILLFACTOR

Fill

Добавление данных в конец таблицы

Ненулевое коэффициент заполнения, отличное от 0 или 100 может быть хорошо для исполнения, если новые данные распределены равномерно по всему столу. Однако, если все данные добавлены в конец таблицы , пустое пространство на страницах индекса не будет заполнено. Например, , если столбец ключа индекса является столбцом IDENTITY , ключ для новых строк всегда равен , а строки индекса - , логически добавленные в конец индекса . Если существующие строки будут обновлены данными, которые удлиняют размер строк, используйте коэффициент заполнения меньше 100. Дополнительные байты на каждой странице помогут свести к минимуму разбиение страниц , вызванное дополнительной длиной в строках.

Таким образом, вещество заполняющего вещества для строго монотонных ключей ...? Особенно, если это низкий объем записи

Answer 3

Нет, совсем нет. Отрицательные значения так же верны, как и INTEGERS как положительные. Нет проблем.В основном, внутри, они всего лишь 4 байта на сумму нулей и единиц :-)

Marc

Answer 4

Вы задаете неправильный вопрос!

Если вы создаете кластерный индекс, который имеет fillfactor 100%, каждый раз, когда запись вставляется, удаляется или даже изменяется, разрывы страниц могут возникать, потому что на текущей странице данных индекса нет места для записи изменения ,

Даже при регулярном обслуживании индексов коэффициент заполнения 100% работает на столе, где вы знаете, какие вставки будут выполнены. Более обычное значение составит 90%.

Answer 5

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

Зачем вам нужно вводить отрицательный идентификатор?

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

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

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

Кроме того, чтобы подтвердить, могу ли я, коэффициент заполнения 100% для первичного ключа с кластерным индексом (например, целое число идентификаторов), не приведет к разрыву страниц для последовательных вставок!