Перестроение индекса на кластерном индексе GUID?
У меня есть большая таблица с кластеризованным индексом в столбце GUID (uniqueidentifier). Таким образом, строки не находятся в каком-либо логическом порядке, они физически сортируются по этому случайно сгенерированному идентификатору.
Имеет ли смысл перестроение индекса для такой таблицы? Или я могу просто пропустить это и выполнить только обновление статистики? Это для SQL Server 2019 Enterprise Edition.
В любом случае строки не будут располагаться в каком-либо порядке (дата, инкрементальный идентификатор и т. д.), они будут идти в хаотическом порядке друг за другом, даже после перестроения индекса.
Я смотрю, имеет ли вообще смысл перестроение индекса в таком случае.
На вопрос «Имеет ли x смысл» можно ответить только в контексте «Каков желаемый результат?». Это статическая таблица и вы пытаетесь сэкономить место? Вы каким-то образом пытаетесь повысить производительность? Что-то еще?
Ответы 2
Это обширный вопрос, но я попробую ответить.
В SQL Server таблицы с «кластерным индексом» представляют собой смесь таблицы и индекса. Они имеют внутреннюю структуру, которая ближе к структуре «чистого» индекса (чем к «чистой» некластеризованной таблице). Записи не просто физически сложены или упорядочены одна за другой. Затем, если вы выполняете много операций UPDATE или DELETE, эта внутренняя структура потребует некоторой реорганизации, и перестроение может быть полезным с точки зрения производительности.
На самом деле, мое последнее предложение справедливо и для некластеризованной таблицы (которая не может быть перестроена так же, как индекс) или «вторичного» индекса.
Это общий ответ, не касающийся моего вопроса о кластерном индексе в столбце GUID, где записи сортируются по случайно сгенерированному идентификатору.
В GUID PK нет ничего особенного (кроме того, что это плохая идея), поэтому ответ применим здесь, вы все равно выполняете поиск по некоторому значению, которое может принести пользу компактному хранилищу.
@BalazsKiss Как я уже сказал, я попробовал дать «общий ответ», потому что это был (очень) широкий вопрос. На самом деле ваш вопрос был настолько широким и неконкретным, что его уже закрыли. Пожалуйста, спрашивайте правильно, будьте благодарны и посмотрите свой собственный пост, прежде чем голосовать против.
Сказал это. «общий ответ» включал в себя размышления и советы, которые непосредственно применимы к вашему случаю. Т.к. дело не только в идентификаторах, но и в том, что вы будете делать с уже вставленными данными. Сценарий полностью зависит от того, выполняете ли вы просто INSERT или нет.
Имеет ли смысл перестроение индекса для такой таблицы? Или я могу просто пропустить это и выполнить только обновление статистики?
Пропустите это. Случайные идентификаторы GUID приведут к разделению страниц при большинстве вставок, но в устойчивом состоянии этого индекса будет поддерживаться ~60 % свободного места.
Если вы перестроите страницу без коэффициента заполнения, после перестроения вы создадите массу разделений страниц. А если перестроить с коэффициентом заполнения, то вы просто перепишете таблицу без уважительной причины.
Обратите внимание: если вы генерируете значения с помощью newssequentialid, у вас не будет всех разделений страниц и пустого пространства.
1. Вам не хватает других операций DML (а именно UPDATE и DELETE, которые не обязательно используют первичный ключ в предложении WHERE). 2 "Если вы перестраиваете без коэффициента заполнения" Тогда совет должен быть "если вы решили перестроить индекс, то вам следует указать коэффициент заполнения".
Если вам «нужно» иметь кластерный индекс на
uniqueidentifier, по крайней мере, убедитесь, что вы используете NEWSEQUENTIALID. Если вы не можете, то этот столбец действительно не должен быть CI.