2015-03-31 4 views
1

Я слышал, что быстрее выбирать коды вручную («col1, col2, col3 и т. Д.»), А не запрашивать их со «*».Быстро ли запрашивать только определенные столбцы?

Но что, если я даже не хочу запрашивать все столбцы таблицы? Было бы быстрее запросить, например, только «col1, col2» insteaf из «col1, col2, col3, col4»?

В моем понимании SQL должен искать все столбцы в любом случае, и только изменения результата return. Я хотел бы знать, могу ли я добиться выигрыша в производительности, только выбрав правильные столбцы.

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

ответ

6

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

В большинстве случаев это незначительное улучшение. В некоторых случаях улучшение может быть более важным:

  • Если для запроса доступен индекс покрытия, то индекс удовлетворяет запросу без необходимости доступа к страницам данных.
  • Если некоторые поля очень длинные, то записи занимают несколько страниц.
  • Если объем извлекаемых данных представляет собой небольшую часть (думаю, < 10%) общих данных в каждой записи.

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

+0

хорошо подробно ответ. Мой запрос извлекает большие двоичные файлы (изображения), поэтому перечисление других столбцов, когда мне не нужны изображения, будет лучшей идеей, да? – user1019042

2

Вы должны стараться не использовать select *.

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

  • Проблемы с индексацией. Рассмотрим сценарий, в котором вы хотите настроить запрос на высокий уровень производительности. Если бы вы использовали *, и он возвращал больше столбцов, чем вам действительно нужно, серверу часто приходилось выполнять более дорогие методы для извлечения ваших данных, чем в противном случае. Например, вы не сможете создать индекс, который просто покрывал бы столбцы в списке SELECT, и даже если бы вы (включая все столбцы [shudder]), следующий парень, который пришел и добавил столбец базовая таблица заставит оптимизатора игнорировать ваш оптимизированный индекс покрытия, и вы, вероятно, обнаружите, что производительность вашего запроса существенно снизится по незавидной причине.

  • Проблемы с переплетением. Когда вы выбираете *, можно получить два столбца с одинаковыми именами из двух разных таблиц. Это может часто приводить к сбою вашего потребителя данных. Представьте себе запрос, который объединяет две таблицы, каждая из которых содержит столбец с именем «ID». Как бы потребитель узнал, что было? SELECT * также может путать представления (по крайней мере, в некоторых версиях SQL Server) при изменении базовых структур таблиц - the view is not rebuilt, and the data which comes back can be nonsense. И худшая часть этого заключается в том, что вы можете позаботиться о том, чтобы назвать свои столбцы, как хотите, но следующий парень, который приходит, может не знать, что он должен беспокоиться о добавлении колонки, которая столкнется с вашим уже разработанным имена.

Я получил это от this ответ.

1

Я считаю, что эта тема уже пройдена здесь:

select * vs select column

Я считаю, что он покрывает ваши проблемы, а также. Взгляни, пожалуйста.

1

Все ярлыки и значения столбцов занимают некоторое пространство. Отправка их эмитенту запроса вместо поднабора столбцов означает отправку большего количества данных. Больше данных отправляется медленнее.

Если у вас есть столбцы, как id, username, password, email, bio, url

и вы хотите получить только username и password, затем

select username, password ... 

быстрее, чем

select * ... 

, потому что id, email, bio и url отправлены также для последнего, что делает ответ более крупным. Но основная проблема с select * отличается. Это может быть источником несоответствий, если по какой-то причине порядок столбцов изменился. Кроме того, он может извлекать данные, которые вы не хотите получать. Всегда лучше иметь белый список с столбцами, которые вы действительно хотите получить.

Смежные вопросы