Разве плохо иметь индексное пространство больше, чем пространство данных?

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

Часто он говорил мне найти альтернативное решение, потому что «индекс уже больше, чем таблица». Он считает, что индекс должен быть меньше данных, потому что он сказал мне: «Вы когда-нибудь видели индекс в книге? Он намного меньше, чем сама книга, и именно таким должен быть индекс таблицы».

Я не чувствую, что его философия верна, но я не могу бросить ему вызов, потому что он ведущий администратор баз данных и я разработчик. Я чувствую, что если запросу нужен индекс, индекс должен быть просто создан, вместо того, чтобы находить «обходные пути», которые просто делают нечитаемые и не поддерживаемые SP.

Я выбираю только необходимые столбцы. Проблема в том, что я фильтрую по дате, поэтому движок обязательно выполнит сканирование таблицы, чтобы соответствовать столбцам. Запрос выполняется один раз в день, ночью, для сбора статистики, но для его выполнения требуется 15 минут (у нас есть другое жесткое и быстрое правило: ни одна процедура не должна занимать более 3 минут).

Администратор БД показал мне статистику индекса. В этой таблице было около 10 индексов, из которых использовались только 6 (статистика показала ноль хитов по 4 из них). Это большая система с участием более 20 разработчиков. Индексы были созданы по любой причине и, вероятно, больше не используются.

Мы обязаны поддерживать SQL Server 2008, поскольку именно на этом работают тестовые БД. Но клиенты все на 2014 и 2016.

Думайте об индексе как о скользящем переключателе. Вы можете переместить эту ручку переключателя красного треугольника в любом месте вдоль линии, которую вы хотите:

Я обычно не измеряю это с точки зрения размера - я обычно думаю об этом с точки зрения количества индекса, но размер был бы также хорош.

Похоже, ваш администратор БД считает, что переключение слишком далеко вправо - что вы добавили слишком много индексов, а операции удаления / обновления / вставки выполняются слишком медленно.

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

Моя отправная точка обычно 5 и 5: около 5 индексов на таблицу, около 5 или менее полей на индекс. В этом числе нет ничего волшебного - это просто потому, что у меня по 5 пальцев на каждой руке, поэтому мне легко поднять руки и объяснить правила.

Возможно, вам понадобится много индексов LESS, чем 5, когда ваша рабочая нагрузка сильно смещена в сторону операций удаления / обновления / вставки, а у вас недостаточно аппаратных ресурсов для поддержки.

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

Кроме того, желание иметь в таблице больше индексов «The Ozar 5», вероятно, указывает на то, что у вас в таблице много разных типов запросов с интенсивным чтением.

Что, вероятно, указывает на то, что вы можете извлечь выгоду из кластеризованного или некластеризованного индекса columnstore в таблице.

Вместо оптимального индекса для каждого из N различных путей доступа, хранилище столбцов обеспечивает сверхбыстрое сканирование и возможность пропускать ненужные столбцы и сегменты строк. Таким образом, вы можете иметь небольшое количество индексов BTree для сверхкритических транзакций и использовать все ресурсы для хранения в столбце.

Индексы Columnstore предназначены для работы в OLTP-тяжелых рабочих нагрузках с SQL Server 2016+. См. Документацию для оперативной аналитики в реальном времени .

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

Если должность администратора базы данных в вашей компании «отвечает» за эту тему, они могут проанализировать ваш запрос и внести предложения по улучшению дизайна запроса или же ответить за производительность.

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

1. Медленный поиск данных
2. Медленное обновление данных
3. Дополнительные аппаратные ресурсы $$$$

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

Кажется слишком строгим, чтобы запретить индексы> таблица. Если ваша таблица редко меняется (или меняется ночью, когда нет большой конкуренции за ресурсы), и она запрашивается многими разными способами, многие большие индексы могут быть оправданы. Администраторы баз данных также должны быть осторожны, чтобы не сунуть носы там, где им нет места. Если он дает вам / вашей системе ограничение в гигабайтах, ему не должно быть слишком важно, как используется это пространство. Если он перегружен работой, возможно, поэтому.

Однако есть много вещей, чтобы рассмотреть:

• Множество индексов замедляет вставку / обновление / удаление. Поэтому, если ваша таблица сильно меняется, будьте осторожны, чтобы не сделать их слишком много.
• Космос тоже может быть проблемой. Не только потому, что гигабайты стоят денег (не очень много в настоящее время), но и время, поскольку резервное копирование будет медленнее (в зависимости от того, как выполняется резервное копирование).
• Большинство серьезных баз данных можно отслеживать, чтобы найти индексы, которые используются редко или никогда не используются. Подумайте об отказе от некоторых из них.
• Иногда вы думаете, что вам нужен индекс, но при более тщательном изучении запроса его можно настроить и переписать по-разному с тем же результатом и без необходимости в индексе. Используйте план объяснения, чтобы увидеть, используется ли индекс.
• Иногда последний столбец (столбцы) может быть удален из индекса из нескольких столбцов без значительного снижения производительности. И иногда это может даже сделать запросы быстрее, потому что область хранения индекса меньше, и большая часть индекса будет храниться / кэшироваться в памяти в любой момент времени.
• Индексы на основе функций могут заменить обычные, чтобы сэкономить больше места. Пример: вместо запроса полной фамилии, запросите первые две буквы также ( where substr(surname, 1, 2) = substr(<userinput>, 1, 2) and surname=<userinput>) и create index i on customers(substr(surname,1,2)). Это может быть достаточно быстро, и ваш индекс будет меньше.
• Базы данных поддерживают разные типы индексов. Некоторые типы используют меньше места, чем другие. Может быть, некоторые из ваших индексов можно преобразовать в тип с меньшим объемом пространства? Обязательно сначала разберитесь с различными типами индексов и для каких ситуаций они хороши и плохи.
• Если нечастое пакетное задание - единственное, что требует определенного индекса, рассмотрите возможность создания этого индекса только для этого пакетного задания и затем удалите его.