Каковы вещи, которые вы могли бы учитывать при определении индексов, кластеризованных и некластеризованных для SQL Server? Существуют ли какие-либо анти-шаблоны, о которых должны знать новички БД? Пожалуйста, объясните «Почему» или укажите ссылки, если это возможно.Рекомендации и анти-шаблоны при создании индексов в SQL Server?
Индекс в основном представляет собой «лист обмана». Это позволяет СУБД находить конкретное значение (или диапазон значений) на диске без необходимости сканирования всей таблицы. Как правило, вы платите немного штрафа за INSERT/UPDATE/DELETE за счет индекса, но редко так сильно, что это узкое место. Хорошая СУБД будет использовать индексы только в том случае, если они помогают повысить производительность запросов, поэтому здесь не так много негативных анти-шаблонов; вам не очень больно, если у вас есть дополнительные индексы (если вы не говорите о очень высоко транзакционных таблицах). Тем не менее, тщательная индексация по всем направлениям поможет вам убедиться, что действительно важные из них есть, и лучший способ узнать, что это профилирование вашего приложения.
Ключом к пониманию того, когда и когда не использовать индексы, является понимание того, что они действительно делают под обложками. В двух словах вы хотите их, когда селективность индекса велика (т. Е. Число различных возможных значений велико по сравнению с размером отношения). Так, например, если у вас есть таблица с 10 000 строк, и у вас есть столбец с названием «цвет» в этой таблице, который является «красным» или «синим», это не очень помогает индексу, поскольку СУБД вероятно, придется загружать большую часть страниц в память в любом случае (предполагая случайное распределение). И наоборот, индекс на идентификаторе первичного ключа таблицы (который почти всегда автоматически добавляется) заставит поиск в этой таблице быстро осветить - порядка log (n) - потому что очень небольшое число узлов в дереве должно чтобы найти страницу на диске, где находится запись.
Индексы в большинстве современных систем баз данных реализованы с деревом B +, что является очень крутым вариантом B-Trees, который оптимизирован для медленного вторичного хранилища (дисков вместо памяти). Вы можете получить хорошее представление об их использовании и функциональности от Database Systems: The Complete Book.
The Blunderbus - Индексирующий анти-шаблон, в котором я был виноват в прошлом. Ввод индекса или вариаций одного и того же индекса в столбцы таблицы, не рассмотрев план объяснения или не понимая, как работает оптимизатор.
Вот несколько более индексации антишаблоны, которые я видел или были виновны:
покрытия Одеяло - Размещение индексов таблиц с небольшим или отсутствие роста и (очень) низкой ROWCOUNT. Это контрпродуктивно, так как поиск индекса может занять больше времени, чем сканирование таблицы.
Индекс промышленной прочности - Размещение индекса в столбце первичного ключа. Меня попросили сделать это, чтобы «ускорить» запрос.
Рассмотрите возможность чтения Relational Database Index Design and the Optimizers. Это даст вам массу идей и причин, по которым они хороши.
Я вижу образец людей, просто использующих советник по настройке ядра базы данных и полагая, что он настолько умен, чтобы предлагать наиболее оптимальные индексы и статистику. Это шаблон, которого вы должны избегать.
Вместо этого посмотрите на выходы плана запроса, прежде чем решать, как подойти к оптимизации. Они могут рассказать вам много полезной информации о том, как наилучшим образом подойти к запросу.Часто люди бросают индексы на все виды полей, потому что они думают, что это правильно, игнорируя, что в некоторых случаях любой выигрыш, который они могут достичь, может быть полностью отрицательным из-за влияния самого индекса (множество индексов на таблице может замедлять вставки и обновления).
Подберите книгу по запросу T-SQL от Itzik Ben-Gan (MS Press) в следующий раз, когда вы в книжном магазине (у них будет это). Прочитайте первые 3 главы и расскажет о том, как работает процесс запросов внутри SQL Server - насколько вы работаете с этой конкретной технологией, они могут оказаться самыми важными тремя главами, которые вы когда-либо читали.
Не тестируйте индексы или оптимизируйте запросы без базы данных, заполненной репрезентативными данными.
База данных, как правило, игнорирует любой индекс в булевом поле. Он будет игнорировать его как часть составного индекса. (Тем не менее, см. «Отфильтрованный индекс» в SQL Server 2008.)
Для составных индексов, где будут указаны все значения, перечисляйте их в обратном порядке по мощности (или arity или количеству различных значений в данных .)
Не предполагайте ничего. Испытайте все.
У вас есть только один сгруппированный индекс. Не тратьте его на уникальный индекс, если вы не уверены, что вам действительно нужно почти всегда вытягивать строки, упорядоченные в этой колонке. Вы хотите использовать его для случаев, когда часто выбираются кратность соседних строк.
Индекс «покрытия» - это тот, который сам по себе содержит все поля, необходимые для разрешения выбора. Помните, что индекс, который «почти» покрывает, недостаточно хорош в большинстве критических случаев.
Большинство из того, что вы читаете в онлайн-блогах о разработке индексов, либо ошибочно, либо высоко квалифицировано, либо неприменимо в вашем случае, либо плохо откалибровано в отношении выгоды и стоимости.
Одна вещь, которую я обнаружил, что люди забывают делать, когда индексирование является индексом внешнего ключа. Индексы основного ключа создаются автоматически (я говорю на SQL Server, другие базы данных могут отличаться), но внешние ключи не являются. Но многие люди предполагают, что они (предположительно те же люди, которые предполагают триггеры, будут действовать только по одной записи за раз). Поскольку они почти всегда участвуют в объединениях (зачем еще у вас их?), Они должны быть проиндексированы большую часть времени (исключение было бы очень маленькой таблицей).
Я бы определил свой любимый индексирующий анти-шаблон как: Почему мои запросы настолько медленны - условие, которое происходит, когда люди без базы данных создают большие базы данных и даже не знают достаточно, чтобы помещать на него какие-либо индексы. Типичный симптом находится на доске объявлений, когда человек спрашивает, почему требуется 40 минут, чтобы сделать простой запрос против 50 миллионов записей. Вероятно, этот антипаттерн будет происходить с большим количеством других антипаттеров дизайна баз данных, поскольку кто-то, даже не знакомый с индексацией, вряд ли разработал эффективную или эффективную структуру базы данных.
Внесение кластеризованного индекса в столбец GUID в основном не является хорошей идеей. Кластерный индекс определяет физический порядок хранения данных. Поэтому лучше всего класть кластерный индекс на столбец, который увеличивает или уменьшает и уникален.
(Если индекс Clustered не уникален, SQL Server добавит PK внутри кластерного индекса). Гид - это случайное значение (если только вы не убедитесь, что используете последовательные указатели), поэтому это означает, что каждый раз, когда вы вставляете или обновляете указатель в столбце, который является частью кластерного индекса, Sql Server должен будет перемещать записи вокруг на страницах данных.
Кроме того, попробуйте поместить кластеризованный индекс в столбцы, которые вы часто используете для выполнения поиска «диапазона».
Имейте в виду, что СУБД может потребовать индекс даже на минимальной и статической таблице, чтобы обеспечить ограничение UNIQUE (или PRIMARY KEY). Вы можете утверждать, что СУБД неисправен, но иногда она устанавливает правила. – 2008-12-09 02:56:18
Чтобы быть предельно ясным, в большинстве систем баз данных любой индекс, который вы помещаете в первичный ключ, по определению является избыточным. Другим столь же немым индексом является составной индекс с первичным ключом. – dkretz 2008-12-09 02:58:01