Рассмотрение кластеризованного индекса в отношении различных значений и больших наборов результатов и единой вертикальной таблицы для аудита

Question

Я изучал лучшие практики для создания кластеризованных индексов, и я просто пытаюсь полностью понять эти два предложения, которые перечислены практически в каждом БЛОГЕ или статье по этому вопросу

• Столбцы, которые содержатбольшое количество различных значений.
• Запросы, которые возвращают большие результирующие наборы.

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

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

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

WHERE TABLE = 'TABLENAME'

Но TableName в значительной степени не отличается ... КаждыйРезультирующий набор имен таблиц довольно большой, что, кажется, соответствует этому второму условию, но определенно не является уникальным в большей степени .... Это означает, что все остальное происходит с добавлением 4-байтового Uniquifer (sp?), что делает таблицу намного большеи т.д. ...

Эта ситуация несколько раз возникала у меня, когда я сталкивался с БД, в которых все контакты или некоторые учетные записи были преобразованы в одну таблицу, и они разделялись только параметром TYPE.,Это относится к каждому запросу ....

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

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

Answer 1

Дизайн индекса - это столько же искусство, сколько и наука.

Есть много вещей, на которые следует обратить внимание, в том числе:

• Как к таблице будет обращаться чаще всего: в основном вставки?любые обновления?больше SELECT, чем DML-операторов?Любая таблица аудита, скорее всего, будет содержать в основном вставки, обновления не будут, редко удаляются, если только для данных не установлено ограничение по времени, и некоторые значения SELECT.
• Для кластеризованных индексов следует помнить, что данные в каждом столбцекластеризованный индекс будет скопирован в каждый некластеризованный индекс (хотя, я полагаю, не для UNIQUE индексов).Это полезно, поскольку эти значения доступны для запросов, использующих некластеризованный индекс для покрытия и т. Д. Но это также означает, что физическое пространство, занимаемое некластеризованными индексами, будет намного больше.
• Кластеризацияиндексы обычно должны быть объявлены с ключевым словом UNIQUE или первичным ключом (хотя, конечно, бывают и исключения).Неуникальный кластеризованный индекс будет иметь скрытое 4-байтовое поле, называемое uniqueifier, которое требуется для того, чтобы сделать каждую строку с неуникальным значением ключа адресуемой, и это просто пустая трата пространства, учитывая, что порядок ваших строк в неуникальномгруппировка, очевидно, не очевидна, поэтому попытка сузить область до одной строки все еще является диапазоном.
• Как уже упоминалось, кластеризованный индекс - это физический порядок данных, поэтому вы хотите удовлетворить то, что нужно наилучшим образом.I / O.Это также относится к тому моменту, когда неуникальные кластеризованные индексы имеют порядок, но если данные действительно неуникальны (в отличие от уникальных данных, но при создании индекса отсутствует ключевое слово UNIQUE), вы теряете многоо преимуществах физического упорядочения данных.
• Независимо от какой-либо информации или теории, ТЕСТ ТЕСТ ТЕСТ.Есть много других факторов, которые относятся к вашей конкретной ситуации.

Итак, вы упомянули наличие поля Date, а также TableName.Если комбинация Date и TableName уникальна, их следует использовать в качестве составного ключа в индексе PK или UNIQUE CLUSTERED.Если их нет, найдите другое поле, которое создает уникальность, например UserIDModified.

Хотя большинство рекомендаций должно содержать самое уникальное поле в качестве первого (из-за того, что статистика присутствует только в первом поле)это не относится ко всем ситуациям.Учитывая, что все ваши запросы выполнены на TableName, я бы предпочел поставить это поле первым, чтобы использовать физический порядок данных.Таким образом, SQL Server может читать более релевантные данные за чтение без необходимости искать другие места на диске.Скорее всего, вы также заказываете на Date, поэтому я бы поставил это поле на второе место.Размещение TableName первым вызовет более высокую фрагментацию между INSERT, чем размещение Date первым, но после перестроения индекса доступ к данным будет быстрее, поскольку данные уже сгруппированы (TableName) и упорядочены (Date) какзапросы ожидают.Если вы сначала поставите Date, тогда данные все равно будут упорядочены должным образом, но строки, необходимые для удовлетворения запроса, вероятно, распределены по файлам данных, что потребует большего количества операций ввода-вывода.И, чем больше страниц данных для удовлетворения одного и того же запроса, тем больше страниц в пуле буферов, потенциально вытесняя другие страницы и сокращая продолжительность жизни страниц (PLE).Кроме того, вам действительно нужно будет заполнить поле Date во всех запросах, поскольку любые запросы, использующие только TableName (и, возможно, другие фильтры, но НЕ использующие поле Date), должны будут сканировать кластеризованный индекс или заставлять вассоздайте некластеризованный индекс с TableName на первом месте.

Я бы устал от модели Heap плюс Indexed View.Да, он может быть оптимизирован для вставок, но система все еще должна поддерживать данные в индексированном представлении для всех операторов DML в куче.Опять же, вам нужно будет протестировать, но я не вижу, что это существенно лучше, чем хороший выбор полей для кластерного индекса в таблице аудита.