Детали воздействия на индексы, первичные ключи, уникальные ключи

Question

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

Давайте представим сценарий, подобный:

Таблица А Ключ: с1, с2, с3, с4 Индекс: с7, с3, с2

Таблица B Ключ: с1, с2, с3, с4 Индекс: с1, с5

Все не сгруппированы. Таблицы имеют более 40 полей. Они кормятся ежедневно ночью и имеют некоторые обновления в течение дня.

Таблица A, если больше ключей получают выгоду от ключа, чем от индекса, может ли индекс оказать негативное влияние? Потому что вставка / удаление должно обновлять 2 индекса вместо 1.

Таблица B содержит дополнительное поле в индексе, отсутствующее в ключе.

Может запрос с использованием c1, c5

Польза от этого Ключа ?: Ключ: с1, с2, с3, с4, с5

Чтобы индекс можно было отбросить.

Как влияет порядок полей? Ключ: с1, с2, с3 Ключ: c3, c1, c2

Типичным сценарием для меня является process_date, client_number, operation. И каждый день он передает кучу данных (process_date).

Answer 1

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

Ключом в вашей таблице должен быть минимальный набор столбцов, который однозначно идентифицирует строку. Он не должен содержать дополнительных столбцов. Например, если у меня есть таблица уникальных адресов электронной почты, а мой ключ находится на email_address, тогда у меня может быть только одна строка для «me@here.com». Если я сейчас добавлю описание к ключу, потому что я использую описание во многих моих запросах, то вдруг у меня могут появиться: «me@here.com», «Description # 1» И «me@here.com», «Description # 2" . Ваши данные больше не будут должным образом ограничены, и вы получите большой беспорядок в ваших руках.

Порядок столбцов в вашем ключе может иметь очень значительное влияние в зависимости от запросов, которые вы используете. Например, если вы ищете строки, основанные на c1, c2, то ключ c1, c2, c3 был бы очень полезен. Если ваш ключ c1, c3, c2, тогда он не так полезен.

Представьте себе это так, я хочу, чтобы вы посмотрели в телефонной книге и нашли всех, чья фамилия начинается с "TO". Это довольно простой запрос. Теперь, что если имена были упорядочены по первой букве фамилии, за которой следует третья буква фамилии? Найти эти имена, начинающиеся с "TO", будет очень сложно и отнимает много времени.

Answer 2

Если вы пытаетесь оптимизировать свою стратегию индексирования, вы можете запустить помощник по настройке базы данных или запросить sys.dm_db_index_usage_stats, чтобы узнать, как используются ваши индексы. (Эта статистика очищается при перезапуске процесса SQL Server).

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

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

Answer 3

, если ключом пользуется больше запросов, чем Индекс, может ли индекс повлиять отрицательно? Потому что вставка / удаление имеет обновить 2 индекса вместо 1.

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

Может ли запрос с использованием преимущества c1, c5 из этого ключа ?: ключ: c1, c2, c3, c4, c5

Да, если только несколько строк имеют один и тот же c1, индекс будет очень эффективным.

Какое влияние оказывает порядок поля имеет? Ключ: с1, с2, с3 Ключ: с3, с1, с2

Заказ важен как для фильтрации, так и для заказа. Индекс на (c1, c2) можно использовать для where c1 = 1 и where c1 = 1 and c2 = 1, но не для where c2 = 1. Аналогично, это помогает с order by c1, но не с order by c2.

Answer 4

Если больше ключей извлекает пользу из ключа, чем индекса, может ли индекс оказать негативное влияние?

Да.

Но ...

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

Может ли запрос с использованием c1, c5 извлечь выгоду из этого ключа ?: Ключ: c1, c2, c3, c4, c5

Редко. Алгоритмы запросов редко используют часть ключа или индекса. Обычно это все или ничего. Если весь ключ (или индекс) не может быть использован, то ни один из них не используется.

Легко получить план выполнения запроса и получить четкий ответ на этот вопрос.

Научитесь получать планы выполнения и фактически получать их.

Как влияет порядок полей? Ключ: c1, c2, c3 Ключ: c3, c1, c2

Почти не влияет вообще. В некоторых базах данных это может изменить способ отображения строк, если вы пропустите предложение ORDER BY. В других базах данных это не влияет, поскольку физические строки и порядок индекса ключа разделены.

Вы можете легко удалить и заново создать индекс, проверить планы выполнения и посмотреть, как это повлияет, если таковые имеются.

Единственный способ убедиться в этом - получить планы выполнения и посмотреть на них.