Добавление индексов является к SQL Server когда-нибудь плохой идеей?
У нас есть основанное на SQL Server приложение среднего размера, которое не имеет никаких определенных индексов. Даже на столбцы идентификационных данных. Я намекнул нашему умеренно дорогому консультанту приложения, что, возможно, мы могли бы получить лучшую производительность (особенно, когда наша база данных растет) путем создания некоторых индексов на соответствующих полях, и он сказал:
"Индексы значительно повлияют на другие области применения, и клиенты не должны создавать их ни при каких обстоятельствах".
Кто-либо когда-нибудь слышал о чем-нибудь как это? Есть ли когда-нибудь обстоятельства, где не нужно создавать индексы? Я не вижу ничего специального об этом приложении - оно имеет международные столбцы идентификационных данных, затем много строковых столбцов, набор реляционных таблиц, но ничего специального или странного, что я вижу.
Спасибо!
[РЕДАКТИРОВАНИЕ: столбцы идентификационных данных не используют "спецификацию идентификационных данных", они, кажется, установлены программой, смотря на базу данных с Studio управления, я не могу найти индексы...]
ПРОДОЛЖЕНИЕ: На конференции я спросил генерального директора (и главный архитектор) компании, производящей этот продукт об этом, его ответ состоял в том, что они сопереживали маленький к развертыванию среднего размера, издержки, связанные с поддержанием индексов, будут иметь больше отрицания к полному пользовательскому опыту (приложение делает много записей), чем преимущества индексов сместили бы, но для больших баз данных, они действительно создают индексы. Парень технической поддержки был просто фанатичен и очень бесполезен со своим ответом. Тайна решена.
7 ответов
Наймите меня, и я создам для вас индексы. 14-летний опыт работы с Sybase / SQL Server подсказывает мне, что нужно создавать такие! Черт! индексы. Если в каждой вашей таблице меньше 500 записей.
Я считаю, что размер хеш-узла индекса составляет примерно 1000.
Еще одна вещь, на которую вам нужно обратить внимание, - это нормализовал ли ваш консультант таблицы. Возможно, таблица имеет 500 полей / столбцов, содержащих более одной концептуальной сущности или целую дюжину концептуальных сущностей. И, возможно, поэтому он нервничает по поводу создания индексов, потому что, если в таблице 12 концептуальных объектов, будет как минимум 12 наборов индексов - и в этом случае он абсолютно прав - ни при каких обстоятельствах ... бла-бла.
Однако, если у него действительно есть 500 столбцов или обнаруживаемое множество концептуальных объектов в таблице - он очень-очень плохой инженер по проектированию данных. За все годы работы с более опытными инженерами по данным наши таблицы редко превышают 20 столбцов. 5 на нижней стороне, 10 в среднем. Иногда для повышения производительности мы разрешаем смешивать две сущности в таблице или горизонтализировать вхождения строк в столбцы таблицы.
Когда вы смотрите на дизайн таблицы, вы можете неопытным глазом увидеть записи Product, Project, BuildSheet, FloorPlan, Equipment и т. Д., Все свёрнутые в одну длинную строку. Вы не можете смешать все эти объекты в одной таблице.
Это единственная причина, по которой я знаю, почему он мог посоветовать вам не иметь индексы. Если он это делает, вы должны знать, что он обманным путем представляет свои навыки проектирования данных вашей компании, и вам следует немедленно исключить его из своих еженедельных договорных расходов.
Хорошо, после прочтения поста Ларри - я тоже с ним согласен.
Существует такая вещь, как чрезмерное индексирование, особенно в тяжелых приложениях INSERT и UPDATE с очень большими таблицами. Итак, ответ на вопрос в вашем заголовке - да, иногда добавлять индексы может быть плохой идеей.
Это совсем другой вопрос, чем тот, который вы задаете в основной части своего вопроса, который гласит: «Нормально ли когда-либо иметь НИКАКИХ индексов в базе данных SQL Server». Ответ заключается в том, что если вы не используете базу данных как систему «только для записи», в которой данные добавляются, но читаются только после массового извлечения и преобразования в другое хранилище данных, крайне необычно не иметь некоторых индексов в база данных.
Заявление вашего консультанта достаточно странно, чтобы заставить меня поверить в то, что вы, возможно, упустили некоторую важную информацию из своего описания. Если нет, я бы сказал, что он чокнутый.
Отсутствие индексов на столбцах id звучит очень необычно, и я бы счел любое обоснование их отсутствия очень подозрительным.
Вы должны знать, что если вы выполняете большой объем фиксаций в базе данных, добавление дополнительных индексов повлияет на скорость вставки, но нет индекса на id? Ничего себе.
Хотя было бы неплохо получить лучшее обоснование того, как именно добавление дополнительных индексов может вызвать проблемы.
В большинстве обычных приложений влияние индексов на производительность вставки не является проблемой. Обычно вам лучше создать индекс, и если производительность вставки резко упадет (чего, вероятно, не будет), вы можете попробовать что-нибудь еще. Очевидно, есть некоторые исключения, в которых вам следует быть более осторожными, например, таблицы, которые используются для ведения журнала.
Как уже упоминалось, дисковое пространство может быть проблемой.
Создание нерелевантных индексов (например, дубликатов) также будет тратить микросекунды и иногда приводить к плохому плану выполнения запроса.
Другая проблема, с которой я столкнулся, связана со странным кодом сторонних приложений, которые генерируют части базы данных во время выполнения и могут удалять или блокировать индексы, о которых они не знают.
Однако в подавляющем большинстве случаев тщательно подобранный индекс принесет только пользу.
Столбцы с ключевыми ограничениями в любом случае будут иметь неявный индекс. Так что, если вы всегда выбираете по первичному ключу, нет смысла добавлять дополнительные индексы. Если вы выбираете по другим критериям, имеет смысл добавить индексы для тех столбцов, по которым вы запрашиваете.
Это также зависит от того, насколько загружены ваши данные. Если вы вставляете чаще, чем запрашиваете, то накладные расходы на поддержание актуальности индексов могут замедлить ваши вставки.
Но сказать, что «не следует создавать [индексы] ни при каких обстоятельствах», - это немного.
Я бы порекомендовал вам запустить инструмент SQL Server Profiler с некоторыми вашими запросами. Этот инструмент порекомендует, какие индексы добавить, которые будут иметь наибольшее влияние на производительность.
Есть ли у вас свободное место на диске? Я видел случаи, когда индексы весили больше, чем таблица.
Однако никаких индексов не существует! Этого не может быть, кроме случаев, когда для всех операций чтения требуется вся таблица.
чем больше у вас индексов, тем медленнее будет происходить вставка и модификация данных. Убедитесь, что вы добавляете индексы по мере необходимости и пишете запросы, которые могут использовать преимущества этих индексов, также если уровень селективности вашего индекса низкий, он не будет использоваться эффективно
.