Сомнения в индексации SQL Server

Question

Индексирование используется для повышения производительности SQL-запросов, но мне всегда было трудно решить, в какой ситуации мне следует использовать индекс, а в каких нет. Я хочу уточнить некоторые из моих сомнений относительно некластеризованного индекса

1. Что такое некластеризованный индексный ключ. Как сказано в книге, каждая строка индекса некластеризованного индекса содержит значение некластеризованного ключа, поэтому это означает, что это столбец, в котором мы создали некластеризованный индекс, т.е. если создан индекс по empname varchar (50), то некластеризованный ключ будет это empname.

2. Почему Желательно создавать индекс для столбца с небольшой шириной. Это связано с тем, что сравнение столбца с большей шириной занимает больше времени для механизма SQL-сервера, либо из-за того, что оно будет увеличивать иерархию промежуточных узлов, поскольку размер страницы фиксирован, поэтому столбец с большей шириной страницы или индексной строкой будет содержать.

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

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

5. Если столбец, используемый в индексации, не уникален, как он находит фактическую строку данных из таблицы.

Пожалуйста, обратитесь к любой книге или учебнику, которые будут полезны, чтобы рассеять мои сомнения.

Answer 1

Сначала я думаю, что мы должны охватить, что такое фактический индекс.Обычно в СУБД индексы реализуются с использованием варианта B-дерева (вариант B + является наиболее распространенным).Короче говоря, подумайте о бинарном дереве поиска, оптимизированном для хранения на диске.Результатом поиска ключа в B-дереве обычно является первичный ключ таблицы.Это означает, что если поиск в индексе завершен, и нам нужно больше данных, чем имеется в индексе, мы можем выполнить поиск в таблице, используя первичный ключ.

Пожалуйста, помните, что когда мы думаем о производительности дляСУБД, мы обычно измеряем это в обращениях к диску (я решаю игнорировать блокировку и другие проблемы здесь), а не так много процессорного времени.

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

2) Возвращаясь к нашей модели измерения производительности - если индексный ключ имеет небольшую ширину (умещается в небольшое количество байтов), это означает, что на каждый извлекаемый нами блок дисковых данных мы можем поместить больше ключей - и, таким образом, выполнять поиск вB-дерево намного быстрее, если вы измеряете дисковый ввод-вывод.

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

4) Если вывыполняется запрос, например, так:

SELECT something, something_else FROM sometable t1 WHERE akey = 'some value'

В таблице с индексом, определенным так:

CREATE INDEX idx_sometable_akey ON sometable(akey)

Если у sometable есть много строк, где akey равно 'некоторому значению«это означает, что много поисков как в индексе, так и в фактической таблице для получения значений что-то и что-то.Принимая во внимание, что если есть большая вероятность, что эта фильтрация возвращает несколько строк, это также означает меньшее количество обращений к диску.

5) См. Более раннее объяснение

Надеюсь, это поможет:)