Влияет ли количество столбцов в представлении на производительность?

Question

У меня есть представление, которое извлекает около 200 столбцов из таблицы, без объединений. Проки, которые используют представление, используют только около 10 столбцов. Влияет ли наличие дополнительных 190 столбцов на производительность при использовании представления?

РЕДАКТИРОВАТЬ: просто чтобы уточнить на основе исходного комментария спрашивающего, запрос в его процедуре использует только 10 столбцов из 200. Вопрос в том, вызывает ли это снижение производительности, поскольку базовое представление содержит 200 столбцов, или оптимизатор знает использовать только 10 столбцов и игнорировать знания представления 190 других?

Спасибо

Chris

Answer 1

190 лишних столбцов определенно повлияют на вашу производительность. Адам довольно хорошо объясняет это в своем блоге: http://jahaines.blogspot.com/2009/06/superfluous-columns-more-than-bad-habit.html

Answer 2

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

Если представление просто ограничивает столбцы, но не содержит предложения WHERE, это неопределенно - см. Подробности ниже:

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

Это очень легко проверить:

1. Выполнить запрос

   select * from myView where someNonIndexedColumn = someValue

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

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

3. Теперь выберите пару столбцов, которые находятся в индексе исходной таблицы, например, убедитесь, что запрос по ним должен использовать индекс покрытия. Скажем, C1 и C2 в индексе I1.

4. Пробег

   select C1, C2 from myTable where C1=x and C2=Y

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

5. Пробег

   select C1, C2 from myView where C1=x and C2=Y

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

Я подозреваю, что он выполнит сканирование таблицы, и в этом случае вы ответите: «Extr 190 столбцов - плохая вещь для производительности» - в основном, все негативы в связанной статье Райана Фоннетта применимы к вашему мнению.

Если (маловероятно) использование индекса покрытия в # 5, то тот факт, что у них 190 столбцов, не имеет значения.

Answer 3

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

Answer 4

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

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

В любом случае, не очень элегантно запрашивать столько ненужных столбцов. Почему бы не адаптировать ваш запрос так, чтобы он запрашивал только нужные столбцы. Я предполагаю, что вы используете «select * from ...», что порождает другую проблему: когда кто-то меняет представление (добавляет столбцы или удаляет столбцы), ваша программа блокируется.