Это плохо, чтобы иметь некластерный индекс, который содержит первичный ключ от кластерного индекса?
Если у Вас есть таблица с кластерным индексом на Первичном ключе (интервал), действительно ли это избыточно и плохо, чтобы иметь одно (руда больше) некластерные индексы, которые включают тот столбец первичного ключа как один из столбцов в некластерном индексе?
4 ответа
На самом деле могут быть веские причины для создания некластеризованного индекса , идентичного кластеризованному. Причина в том, что кластеризованные индексы несут багаж данных строк, и это может привести к очень низкой плотности строк. Т.е. у вас может быть 2-3 строки на странице из-за широких полей, которых нет в кластеризованном ключе, но ключ кластеризованного индекса составляет всего, скажем, 20 байтов. Наличие некластеризованного индекса на точно тех же ключей и порядка, что и кластеризованный индекс, даст плотность 2-3 сотен ключей на страницу. На множество агрегированных запросов, типичных для рабочей нагрузки OLAP / BI, можно более эффективно ответить с помощью некластеризованного индекса просто потому, что он уменьшает количество операций ввода-вывода в сотни раз.
Что касается некластеризованных индексов, которые содержат части кластеризованного ключа или даже те же самые ключи, но в другом порядке, то все ставки отменены, поскольку они, очевидно, могут использоваться для множества запросов.
Итак, ответ на ваш вопрос: Это зависит .
Для более точного ответа вам нужно будет поделиться точной схемой вашей таблицы (таблиц) и точными задействованными запросами.
Я с Ремусом в этом вопросе - кластеризованный индекс на самом деле не индекс - он говорит вам, как данные организованы на страницах. (В вашем случае это также первичный ключ, но это не обязательно должно быть одно и то же). Некластеризованные индексы включают информацию о локаторе строк, так что да, она избыточна.
Но , если некластеризованный индекс покрывает и , закладку строки данных использовать не нужно, ее можно использовать лот более эффективно, чем кластеризованный индекс, и эффективность увеличивается по мере увеличения отношения размера строки данных к размеру некластеризованного индекса.
Я обнаружил, что если вы хорошо разбираетесь в путях доступа в рабочей нагрузке запросов, то иногда можно использовать несколько выборочных покрывающих некластеризованных индексов для полного исключения вариантов кластеризации - таблица кучи, PK и несколько хороших некластеризованных индексов, и все готово.
Да, обычно в этом нет необходимости, поскольку столбцы кластеризованного индекса уже добавлены к каждой индексной записи в некластеризованном индексе.
Почему? Значение кластеризованного ключа - это то, что действительно позволяет SQL Server "найти" строку данных - это "указатель" на фактические данные - поэтому, очевидно, он должен храниться в некластеризованном индексе. Если вы нашли "Smith, John" и вам нужно узнать больше об этом человеке, вам нужно перейти к фактическим данным --> и это делается путем включения значения ключа кластеризации в индексный узел некластеризованного индекса.
Значение кластеризованного ключа уже есть, и поэтому, как правило, добавлять это значение снова, явно, в ваш некластеризованный индекс излишне и ненужно. Это плохо тем, что просто тратит место впустую, не давая вам никакой выгоды.
100% ответа нет, но ответ почти определен.
Другие индексы помогают в объединениях и сортировке (как правило). Учитывая, что первичный ключ уже проиндексирован, если оптимизатор может присоединиться на основе этого, он будет использовать это.
Если с точки зрения объединения / сортировки необходим другой индекс, какую дополнительную помощь дает PK в смеси индексов? Если раньше он не мог присоединиться на основе ПК, то не присоединится сейчас. И с сортировкой это тоже не поможет.