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

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

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

4b9b3361

Ответ 1

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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