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

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

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

Итак, да, явных индексов можно избежать, если нужно работать с небольшим набором данных.

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

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

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

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

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

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

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

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

Совершенно неверно. 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.

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

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

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

По-разному. Таблица справочная?

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

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

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

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

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

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

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

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

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

Даже если у вас есть индекс, SQL Server может даже не использовать его, в зависимости от статистики для этой таблицы. И если вы планируете добавить индекс для отчета, который будет запускаться не более двух раз в год, имейте в виду, что штрафы INSERT / UPDATE за добавление индекса будут действовать ВСЕ ВРЕМЯ. Перед добавлением индекса спросите себя, стоит ли оно снижения производительности.

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

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

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

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

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

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

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