Я отвечаю за меньшую БД, 300+ сотен мегабайт, 100 таблиц, около 45 пользователей попадают в нее в течение рабочего дня. В основном читает, но изрядное количество обновлений и вставок. Я медленно изучал структуру БД, чтобы получить от нее некоторую производительность. Я слышал, что изучение индексов - хорошее место для начала. Почти все индексы для таблиц указанной БД кластеризованы, некоторые из них не кластеризованы.
Есть ли преимущество в скорости по сравнению с кластеризованными или некластеризованными? У меня есть план обслуживания (да, да, я знаю), который переорганизует и восстанавливает индексы каждую ночь перед резервным копированием diff. Достаточно ли этого на данный момент, пока я не получу более полное представление о формировании и использовании индексов?
Есть ли / есть ли скрипт (ы), который поможет мне просмотреть «производительность» различных индексов? Насколько большую банку с червями я влез?
Кластерный индекс определяет физический порядок данных в таблице и особенно эффективен для столбцов, в которых часто выполняется поиск диапазонов значений. Они также эффективны для поиска конкретной строки, когда индексированное значение уникально.
Обычно (есть исключения) кластеризованный индекс должен находиться в столбце, который монотонно увеличивается - например, в столбце идентификаторов или в каком-либо другом столбце, в котором значение увеличивается, - и быть уникальным. Во многих случаях первичный ключ является идеальным столбцом для кластерного индекса (но не помещайте кластерный индекс в столбец uniqueidentifier / GUID).
Из этого Статья MSDN:
Прежде чем создавать кластерные индексы, узнайте, как будут осуществляться доступ к вашим данным. Рассмотрите возможность использования кластерного индекса для:
- Столбцы, содержащие большое количество различных значений.
- Запросы, возвращающие диапазон значений с использованием таких операторов, как BETWEEN,>,> =, <и <=.
- Столбцы, к которым осуществляется доступ последовательно.
- Запросы, возвращающие большие наборы результатов.
- Столбцы, к которым часто обращаются запросы, включающие предложения join или GROUP BY; обычно это столбцы внешнего ключа. Индекс столбца (столбцов), указанного в предложении ORDER BY или GROUP BY, устраняет необходимость в SQL Server для сортировки данных, поскольку строки уже отсортированы. Это улучшает производительность запросов.
- Приложения типа OLTP, в которых требуется очень быстрый поиск одной строки, обычно с помощью первичного ключа. Создайте кластеризованный индекс по первичному ключу.
Кластерные индексы не подходят для:
- Столбцы, которые претерпевают частые изменения: это приводит к перемещению всей строки (поскольку SQL Server должен сохранять значения данных строки в физическом порядке). Это важное соображение в системах обработки больших объемов транзакций, где данные имеют тенденцию быть нестабильными.
- Широкие ключи: значения ключей из кластеризованного индекса используются всеми некластеризованными индексами в качестве ключей поиска и поэтому хранятся в каждой конечной записи некластеризованного индекса.
На SQLServerpedia.com есть несколько хороших статей / руководств по настройке индекса: Индексирование запросов DMV и Использование правильных индексов для оптимальной производительности.
Я читал, что использовать суррогатный ключ и кластеризованный индекс для этого столбца - это очень хорошая практика. Обычно это будет столбец типа int, который будет автоматически увеличиваться (IDENTITY), или уникальный идентификатор (сделайте его последовательный GUID чтобы в дальнейшем избежать проблем с производительностью!).
При этом ваши запросы будут выполнять СОЕДИНЕНИЯ с этими суррогатными ключами в таблицах, что обеспечит вам производительность и масштабируемость.
Что касается других (некластеризованных) индексов, этот выбор зависит от того, как ваши клиенты используют ваше приложение. Слишком много индексов означает катастрофу для вставок / обновлений. Недостаточные индексы замедляют чтение. Вам нужно будет найти баланс между ними. Столбцы, которые используются вместе с поиском, являются логическими кандидатами для индексации, включая составные (многостолбцовые) индексы (в этом случае обратите внимание на порядок столбцов).
Если вы хотите пофантазировать, создайте отдельную базу данных OLAP для отчетов по историческим данным.