Производительность SQL Server и значения кластеризованного индекса - PullRequest
0 голосов
/ 25 мая 2009

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

Приведут ли отрицательные значения к дополнительному разбиению страницы и замедлению вставки?

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

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

Ответы [ 5 ]

2 голосов
/ 26 мая 2009

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

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

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

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

2 голосов
/ 25 мая 2009

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

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

Изменить, после комментариев Fill factor:

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

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

Однако, от BOL, FILLFACTOR

Fill

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

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

Значит, фактор заполнения имеет значение для строго монотонных ключей ...? Особенно если это мало громкость пишет

1 голос
/ 25 мая 2009

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

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

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

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

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

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

1 голос
/ 25 мая 2009

Вы задаете не тот вопрос!

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

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

1 голос
/ 25 мая 2009

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

Марк

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...