Зная, что индексированный столбец приводит к лучшей производительности, стоит ли индексировать все столбцы во всех таблицах базы данных? Каковы преимущества/недостатки такого подхода?
Если это достойно, есть ли способ автоматического создания индексов в SQL Server? Мое приложение динамически добавляет таблицы и столбцы (в зависимости от конфигурации пользователя), и я хотел бы, чтобы они автоматически индексировались.
Трудно представить себе сценарии реального мира, где индексирование каждого столбца было бы полезно по причинам, упомянутым выше. Для типа сценария потребуется куча разных запросов, причем все будут иметь доступ только к одному столбцу таблицы. Каждому запросу может быть доступ к другому столбцу.
В других ответах не рассматриваются проблемы во время выбора стороны запроса. Очевидно, что сохранение индексов является проблемой, но если вы создаете таблицу /s один раз, а затем читаете много и много раз, накладные расходы на обновления/вставки/удаления не рассматриваются.
Индекс содержит исходные данные и указывает на записи/страницы, на которых находятся данные. Структура индекса позволяет быстро делать такие вещи, как: найти одно значение, получить значения по порядку, подсчитать количество различных значений и найти минимальные и максимальные значения.
Индекс не только занимает пространство на диске. Что еще более важно, он занимает память. И проблема памяти часто является фактором, определяющим производительность запросов. В общем случае построение индекса по каждому столбцу займет больше места, чем исходные данные. (Одним из исключений будет столбец, который является относительно широким и имеет относительно немного значений.)
Кроме того, для удовлетворения многих запросов вам может понадобиться один или несколько индексов плюс исходные данные. Кэш вашей страницы заполняется данными, что может увеличить количество промахов в кэше, что, в свою очередь, наносит дополнительные накладные расходы.
Интересно, действительно ли ваш вопрос является признаком того, что вы недостаточно моделировали свои структуры данных. Есть несколько случаев, когда вы хотите, чтобы пользователи создавали постоянные постоянные таблицы. Более типично их данные будут храниться в заранее определенном формате, который вы можете оптимизировать для требований к доступу.
Нет, потому что вы должны принимать во внимание, что каждый раз, когда вы добавляете или обновляете запись, вы должны пересчитывать свои индексы, а наличие индексов для всех столбцов займет много времени и приведет к снижению производительности.
Таким образом, базы данных, такие как хранилища данных, где используются только запросы на выборку, это хорошая идея, но для обычной базы данных это плохая идея.
Кроме того, это не потому, что вы используете столбец в предложении where, вы должны добавить к нему индекс. Попробуйте найти столбец, в котором запись будет почти все уникальной, как первичный ключ, и которую вы не будете часто редактировать. Плохая идея заключалась бы в том, чтобы индексировать пол человека, потому что существует только 2 возможных значения, и результат индекса будет только разбивать данные, тогда он будет искать почти в каждой записи.
Нет, вы не должны индексировать все свои столбцы, и есть несколько причин для этого:
Вам гораздо лучше использовать планы Explain и доступ к данным и добавлять индексы, когда это необходимо (и только при необходимости, IMHO), а не создавать их все впереди.
Нет, в индексировании есть накладные расходы, поэтому индексирование всех столбцов приведет к замедлению всех операций вставки, обновления и удаления. Вы должны индексировать столбцы, которые вы часто ссылаетесь в предложениях WHERE, и вы увидите преимущество.
Индексы занимают место. И они занимают время, чтобы создавать, перестраивать, обслуживать и т.д. Таким образом, нет гарантированного возврата производительности для индексации только любого старого столбца. Вы должны индексировать столбцы, которые дают производительность для операций, которые вы будете использовать. Индексы помогают читать, поэтому, если вы в основном читаете, индексируйте столбцы, которые будут искаться, отсортированы или объединены с другими таблицами реляционно. В противном случае это будет дороже, чем вы можете видеть.