Нет индексов на маленьких столах?

Question

«Мы должны забыть о малой эффективности, скажем, в 97% случаев: преждевременная оптимизация - корень всех зол» (Дональд Кнут). Мои таблицы SQL вряд ли содержат более нескольких тысяч строк каждая (и это большие!). Помощник по настройке ядра СУБД SQL Server отклоняет объем данных как несущественный. Так что я даже не должен думать о том, чтобы поместить в эти таблицы явные индексы. Правильно?

Answer 1

Значение индексов в ускорении чтения. Например, если вы выполняете много операций SELECT на основе диапазона дат в столбце даты, имеет смысл поместить индекс в этот столбец. И, конечно же, обычно вы добавляете индексы к любому столбцу, к которому собираетесь присоединиться, с какой-либо значительной частотой. Повышение эффективности также связано с отношением размера ваших типичных наборов записей к количеству записей (то есть захват 20/2000 записей дает больше преимуществ от индексации, чем захват 90/100 записей). Поиск по неиндексированному столбцу - это, по сути, линейный поиск.

Стоимость индексов зависит от операций записи, поскольку для каждой вставки также требуется внутренняя вставка в каждый индекс столбца.

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

Требуется очень мало времени, чтобы определить и сравнить некоторые из наиболее часто используемых операций вашего приложения как с индексами в столбцах JOIN / WHERE, так и без них. Я предлагаю вам это сделать. Также разумно отслеживать ваше производственное приложение и выявлять самые дорогие и наиболее частые запросы, а также концентрировать свои усилия по оптимизации на пересечении этих двух наборов запросов (что может означать индексы или что-то совершенно другое, например выделение большего или меньшего количества памяти для запросить или объединить кэши).

Answer 2

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

Разные СУБД будут иметь разные руководящие принципы для выбора, следует ли индексировать столбцы на основе различных факторов, включая размер таблицы, и именно это следует учитывать.

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

Answer 3

Столбцы первичного ключа будут проиндексированы для ограничения уникальности. Я бы все равно проиндексировал все столбцы внешнего ключа. Оптимизатор может игнорировать ваш индекс, если он не имеет значения.

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

Answer 4

Это зависит. Является ли таблица справочной таблицей?

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

Как правило, если таблица является справочной, обновления в ней будут относительно редкими. Это означает, что снижение производительности при обновлении индекса также будет относительно редким. Если оптимизатор передаст индекс, снижение производительности оптимизатора будет незначительным. Пространство, необходимое для хранения индекса, также будет незначительным.

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

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

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

Answer 5

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

Это может показаться ненужным с такой маленькой базой данных. Как уже говорили другие: до тех пор, пока ваша база данных будет такой маленькой, как вы описали, запросы все равно будут достаточно быстрыми, а индексы на самом деле не нужны. Они могут даже замедлять вставки и обновления, но если у вас нет особых требований, это не имеет значения для такой маленькой базы данных.

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

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

Answer 6

Абсолютно неверно. 100% неверно. Не ставьте миллион бессмысленных индексов, но вам нужен Первичный ключ (в большинстве случаев), и вы хотите, чтобы он КЛАСТЕРИРУЛ правильно.

И вот почему:

SELECT * FROM MySmallTable <-- No worries... Index won't help

SELECT
    *
FROM
    MyBigTable INNER JOIN MySmallTable ON... <-- Ahh, now I'm glad I have my index.

Вот хорошее правило.

"Поскольку у меня есть ТАБЛИЦА, я, вероятно, захочу запросить ее через некоторое время ... Если я собираюсь запросить ее, я, вероятно, сделаю это согласованным образом ... <- Вот как вы должны индексировать таблицу. </p>

РЕДАКТИРОВАТЬ: я добавляю эту строку: Если у вас есть конкретный пример, я покажу вам, как его индексировать, и сколько экономии вы получите от этого. Пожалуйста, предоставьте таблицу и пример того, как вы планируете использовать эту таблицу.

Answer 7

Если строки имеют узкую ширину и несколько тысяч строк умещаются, скажем, на 10-20 8K-страницах, маловероятно, что оптимизатор SQL выберет использование индекса, даже если вы его создадите.

Answer 8

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

Но иногда они могут дать огромный импульс, как я обрисовал в общих чертах здесь .

Answer 9

Индексы часто создаются неявно при использовании уникальных ограничений. Я бы не стал избегать их использования в этом случае!

Answer 10

Ставьте индексы ТОЛЬКО если вам нужно:)
Бывают случаи, когда размещение индексов может фактически снизить производительность, в зависимости от того, для чего используется таблица ...
Таким образом, другими словами, вам следует подумать о размещении индексов в таблицах, когда это необходимо, как определено профилированием приложения.