Повышение производительности, когда SQL-запрос ограничен по сравнению с вызовом всей строки?

Question

Насколько выигрыш в производительности заключается в выборе в запросе только обязательного поля вместо запроса всей строки? Например, если у меня есть строка из 10 полей, но мне нужно только 5 полей на дисплее, стоит ли запрашивать только эти 5 полей? Каково преимущество производительности с этим ограничением по сравнению с риском того, что в случае необходимости придется вернуться назад и добавить поля в запросе sql позже?

Answer 1

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

Answer 2

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

Как риск добавления полей позже? изменение запросов в соответствии с меняющимися требованиями является естественной частью процесса разработки.

Answer 3

Единственное известное мне преимущество явного именования ваших столбцов в вашем операторе select - это то, что если переименовать столбец, который использует ваш код, ваш оператор select потерпит неудачу перед вашим кодом. Еще лучше, если ваш оператор select находится внутри proc, ваш proc и скрипт DB не будут компилироваться. Это очень удобно, если вы используете такие инструменты, как VS DB edition, для компиляции / проверки сценариев БД. В противном случае разница в производительности будет незначительной.

Answer 4

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

Очевидно, что если дополнительные поля содержат мегабайтный объект, уравнение искажается. Но мой опыт показывает, что накладные расходы на транзакции того же порядка или больше, чем фактические полученные данные. Я помню смутно много лет назад, чем "пустой" NOP TNS-запрос составляет около 100 байтов на проводе.

Answer 5

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

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

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