Является ли добавление индексов в SQL Server плохой идеей?

Question

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

«Индексы существенно влияют на другие области приложения, и клиенты не должны создавать их ни при каких обстоятельствах».

Кто-нибудь когда-нибудь слышал что-нибудь подобное? Были ли обстоятельства, когда не нужно создавать индексы ? Я не вижу ничего особенного в этом приложении - у него есть столбцы int, затем множество строковых столбцов, куча реляционных таблиц, но ничего особенного или странного, что я вижу.

Спасибо!

[РЕДАКТИРОВАТЬ: столбцы идентификаторов не используют «спецификацию идентификаторов», они, похоже, устанавливаются программой, просматривая базу данных с помощью Management Studio, я могу найти NO indexes ...]

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

Answer 1

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

Это совершенно другой вопрос, чем тот, который вы задаете в основной части вашего вопроса, а именно: «Нормально ли когда-либо НЕТ индексов в базе данных SQL Server». Ответ заключается в том, что, если вы не используете базу данных в качестве системы «только для записи», в которой данные добавляются, но считываются только после массового извлечения и преобразования в другое хранилище данных, крайне необычно не иметь некоторые индексы в базы данных.

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

Answer 2

Наймите меня, и я создам для вас индексы. 14-летний опыт работы с Sybase / SQL Server подсказывает мне создавать их! индексов. Если в вашей таблице не менее 500 записей каждая.

Моя идея состоит в том, что индексный хэш-узел приблизительно имеет размер 1000.

Другая вещь, на которую вам нужно обратить внимание, - нормализовал ли ваш консультант таблицы. Возможно, таблица имеет 500 полей / столбцов, содержащих более одного концептуального объекта или целую дюжину концептуальных объектов. И именно поэтому он нервничает по поводу создания индексов, потому что если в таблице будет 12 концептуальных сущностей, то будет хотя бы 12 наборов индексов - в этом случае он абсолютно правдив - ни при каких обстоятельствах ... бла-бла.

Однако, если у него действительно есть 500 столбцов или определенно несколько концептуальных объектов на таблицу - он очень и очень паршивый инженер по проектированию данных. За все мои годы работы с более опытными инженерами данных наши таблицы редко превышают 20 столбцов. 5 на нижней стороне, 10 в среднем. Иногда для повышения производительности мы допускаем смешивание двух объектов в таблице или горизонтализацию вхождений строк в столбцы таблицы.

Когда вы смотрите на дизайн таблицы, вы можете неопытным взглядом увидеть записи Product, Project, BuildSheet, FloorPlan, Equipment и т. Д., Все свернутые в один длинный ряд. Вы не можете смешать все эти объекты в одну таблицу.

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

Хорошо, прочитав пост Ларри, я тоже с ним согласен.

Answer 3

Есть ли у вас свободное место на диске? Я видел случаи, когда индексы весили больше, чем таблица.

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

Answer 4

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

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

Но сказать, что вы «не должны создавать [индексы] ни при каких обстоятельствах» - это немного много.

Я бы порекомендовал запустить инструмент SQL Server Profiler с некоторыми вашими запросами. Этот инструмент порекомендует, какие индексы добавить, которые будут иметь наибольшее влияние на производительность.

Answer 5

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

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

Создание нерелевантных индексов (например, дубликатов) также приведет к потере микросекунд и иногда приведет к неверному плану выполнения запроса.

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

Однако в подавляющем большинстве случаев тщательно подобранный индекс будет только преимуществом.

Answer 6

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

Answer 7

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

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

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