#sql-server #database #optimization #indexing
#sql-server #База данных #оптимизация #индексирование
Вопрос:
Если таблице нужен только 1 индекс, кажется, что кластеризация — это вообще правильный путь. Это быстрее, потому что ему не нужно ссылаться на данные с помощью ключа, а также не занимает дисковое пространство, как это делает некластеризованный индекс.
Мой вопрос в отношении нескольких индексов, лучше ли удалять кластеризованный индекс все вместе? Логика этого заключается в том, что если у вас есть некластеризованные индексы С кластеризованным индексом, они больше не ссылаются напрямую на фактические строки данных, а вместо этого ссылаются на кластеризованный индекс. Таким образом, похоже, что использование кластеризованного индекса в качестве прокси значительно снизит производительность. Кажется, что лучше всего вообще не использовать кластеризованные индексы, если вы считаете, что вам понадобится более 1 индекса в таблице.
Комментарии:
1. Какую базу данных вы используете? MySQL или SQL Server?
2. sql server. 15char
3. ну да, я бы согласился. если вам нужен только 1 индекс, он должен быть кластерным. но для аналитических целей таблицы обычно имеют много индексов, поэтому (n-1) должны быть некластеризованными. и если есть кластеризованный индекс, и происходит сканирование некластеризованного индекса, вместо того, чтобы получать некластеризованные результаты RID, это ссылка на кластеризованный индекс. итак, мой вопрос: если в таблице есть несколько индексов, лучше ли просто исключить кластеризованный индекс, чтобыпоисковые запросы не должны проходить через кластеризованный индекс каждый раз, когда выполняется некластеризованный поиск — это должно сэкономить время
4. Проверьте охватывающие индексы. Таким образом, это не прямой ответ на ваш вопрос, но покрывающий индекс содержит дополнительные поля и может предоставлять информацию без чтения строк из таблицы. Конечно, из-за нехватки памяти.
5. Снижение производительности при использовании логического rid, а не физического rid, возможно, меньше, чем вы предполагаете . Кроме того, если вы храните базовую таблицу в виде кучи, это означает, что ни один индекс вообще не может ее использовать без необходимости выполнять обратный поиск (быстро становится дорогостоящим) или дублировать данные в самом NCI. Это означает, что он хранится дважды и должен поддерживаться дважды.
Ответ №1:
Если таблица имеет правильный кластеризованный индекс, его удаление не имеет смысла.
Если у вас несколько индексов, выберите наилучшего кандидата для кластеризации.
Обычно это ваш ПК.
При создании PK по умолчанию он кластеризуется.
PK — ваш лучший кандидат для кластеризации, если у вас нет особых причин не использовать его.
Я не понимаю вашего утверждения.
«Если у вас есть некластеризованные индексы С кластеризованным индексом, они больше не ссылаются на фактические строки данных, а на кластеризованный индекс. Похоже, что это приведет к значительному снижению производительности «.
Если кластеризованный индекс находится в данных, то ссылка на кластеризованный индекс ссылается на данные. Данные физически организованы кластеризованным индексом. Где наблюдается значительное снижение производительности?
Рекомендации по разработке кластеризованных индексов
За некоторыми исключениями, для каждой таблицы должен быть определен кластеризованный индекс
Если бы одним из этих немногих исключений был другой индекс, он был бы вызван.
Другой некластеризованный индекс не является причиной отсутствия кластеризованного индекса.
Некластеризованные структуры индексов
Локаторы строк в некластеризованных индексных строках являются либо указателем на строку, либо кластеризованным индексным ключом для строки, как описано ниже:
- Если таблица представляет собой кучу, что означает, что у нее нет кластеризованного индекса, указатель строки является указателем на строку. Указатель создается на основе идентификатора файла (ID), номера страницы и номера строки на странице. Весь указатель известен как идентификатор строки (RID).
- Если таблица имеет кластеризованный индекс или индекс находится в индексированном представлении, локатор строк является ключом кластеризованного индекса для строки. Если кластеризованный индекс не является уникальным индексом, SQL Server делает любые повторяющиеся ключи уникальными, добавляя внутренне сгенерированное значение, называемое uniqueifier . Это четырехбайтовое значение не видно пользователям. Он добавляется только тогда, когда требуется сделать кластеризованный ключ уникальным для использования в некластеризованных индексах. SQL Server извлекает строку данных путем поиска в кластеризованном индексе с использованием ключа кластеризованного индекса, хранящегося в конечной строке некластеризованного индекса.
У них была возможность использовать RID, даже если был PK. Как вы думаете, почему кластерный индекс работает медленнее?
Комментарии:
1. @ последний абзац — кластеризация всегда должна быть быстрее, чем некластеризация, потому что кластеризация не должна ссылаться на данные. Но у меня сложилось впечатление, что если уже есть кластеризованный, некластеризованные результаты должны проходить через все кластеризованное индексное B-дерево, чтобы добраться до соответствующего номера строки. Имеет ли это смысл? таким образом, вместо того, чтобы просто ссылаться на номер строки напрямую, как обычно, чтобы получить номер строки, он должен проходить через кластеризованный ПОСЛЕ некластеризованного. Вот откуда происходит снижение производительности..
2. @user3739391 Нет, я этого не понимаю. Если бы RID был быстрее, они бы его использовали. Какие у вас есть доказательства того, что RID работает быстрее? Знаете ли вы структуру RID (в SQL)? Часто встречается несколько индексов. Если бы отсутствие кластеризованного индекса было лучше в сценарии с несколькими индексами, вы бы сочли эту рекомендацию большой и жирной.
3. хорошо, я протестирую это, когда вернусь к работе и свяжусь с вами. и RID НЕ всегда быстрее, но в случае кластеризованного индекса, уже существующего в таблице, он должен быть, потому что он может просто использовать RID для идентификации записи вместо того, чтобы проходить через весь кластеризованный индекс, чтобы найти запись. это просто логично.
4. dba.stackexchange.com/questions/9829/… . Оказывается, это действительно увеличивает производительность на 20-30%, как я и думал.
5. @user3739391 Я не удаляю свои кластеризованные индексы, но это было весело.