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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

Абсолютно неверно. 100% неверно. Не ставьте миллион бессмысленных индексов, но вам нужен основной ключ (в большинстве случаев), и вы действительно хотите, чтобы он был CLUSTERED правильно.

Вот почему:

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.

Здесь хорошее правило.

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

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

Ответ 6

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

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

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

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

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

Ответ 12

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

Ответ 13

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

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