Влияет ли количество возвращаемых столбцов на скорость запроса? - PullRequest
8 голосов
/ 12 мая 2009

Если у меня есть два запроса

SELECT Id, Forename, Surname
FROM Person
WHERE PersonName Like(‘%frank%’)

И

SELECT *
FROM Person
WHERE PersonName Like(‘%frank%’)

Какой запрос будет выполняться быстрее? Является ли условие / таблица присоединения наибольшим фактором или число возвращаемых столбцов?

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

Select - выбирает все

List - Выбирает достаточно для заполнения выпадающего списка

Search - Выбирает все, что отображается в результатах, обычно около 6 или около того столбцов.

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

Итак, для простоты разработки, SELECT * разумно или наивно?

Ответы [ 18 ]

0 голосов
/ 12 мая 2009

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

Я полагаю, что я также видел случаи, когда SELECT * требует, чтобы данные фактически извлекались из объединенной таблицы, в отличие от использования только индексов этой таблицы, чтобы помочь сузить общий набор результатов. Хотя я не могу привести пример этого.

0 голосов
/ 12 мая 2009

Да, это так. В основном:

  • Больше данных должно быть передано с вашего сервера базы данных
  • Сервер базы данных должен получить больше данных

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

0 голосов
/ 12 мая 2009

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

SELECT * FROM TABLE

в вашем коде. Это может привести к нескольким проблемам, только одна из которых - производительность. Два других вопроса, о которых я могу подумать, это использование ресурсов (если вы выбираете столбцы, которые вам не нужны, или кто-то добавляет столбцы позже ... вы возвращаете данные и тратите память) и читабельность кода ( если кто-то видит SELECT * FROM в вашем коде ... он не обязательно будет знать, какие столбцы фактически используются в вашем приложении).

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

0 голосов
/ 12 мая 2009

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

По моему опыту, выбор 3 столбцов вместо выбора * в таблице с 3 столбцами может не оказать заметного влияния на производительность, но по мере увеличения и расширения таблиц вы заметите разницу в производительности.

0 голосов
/ 12 мая 2009

Если у человека есть только Id, Имя и Фамилия, запросы должны быть эквивалентны. Однако время запроса будет расти пропорционально количеству возвращаемых столбцов (действительно объем данных).

Кроме того, если запросу когда-либо понадобятся только эти три столбца, вам следует запрашивать только эти три столбца. Если вы ВЫБИРАЕТЕ * и позже изменяете свою схему, вы просто добавляете дополнительную обработку ко всем вашим запросам, не принося реальной выгоды.

0 голосов
/ 12 мая 2009

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

Если вы действительно хотите использовать *, укажите таблицу, из которой вы хотите получить все столбцы, например SELECT Person. * FROM Person ...

Это сузит объем возвращаемых данных и сделает их немного более читабельными.

0 голосов
/ 13 мая 2009

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

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

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

0 голосов
/ 12 мая 2009

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

Более того, если вы всегда запрашиваете все столбцы, вам потребуется больше памяти на клиенте базы данных и на сервере базы данных для ненужных столбцов. Это может быть очень дорого, если таблица содержит длинные символьные поля, очень много полей и / или больших двоичных объектов. Выбор ненужных столбцов также приведет к перегрузке кэша сервера, поскольку он будет заполнен избыточным содержимым, которое никогда не просматривается клиентом.

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

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