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

Question

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

РЕДАКТИРОВАТЬ: только для пояснения на основе комментария оригинального комментатора запрос в его proc использует только 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, то неизвестно - подробности ниже:

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

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

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

   select * from myView where someNonIndexedColumn = someValue

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

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

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

4. Run

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

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

5. Run

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

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

Мои подозрения в том, что он будет делать сканирование таблицы, в этом случае вы ответ «Extr 190 колонки Bad Thing Для Performance» - в основном, все негативы в связанной статье Райан Fonnett применимы к вашему мнению ,

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

Answer 3

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

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

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

Answer 4

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