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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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