SQL-запрос - выберите * из представления или выберите col1, col2, ... colN из представления
Мы используем SQL Server 2005, но этот вопрос может быть для любого СУБД.
Что из следующего является более эффективным при выборе всех столбцов в представлении?
Select * from view
или же
Select col1, col2, ..., colN from view
Ответы 10
Если вы действительно выбираете все столбцы, не должно быть заметной разницы, просите ли вы * или явно указываете ли вы. SQL-сервер будет анализировать запрос таким же образом примерно за такое же время.
Лучше всего выбирать каждый столбец по имени. В будущем ваша схема БД может измениться, чтобы добавить столбцы, которые вам не понадобятся для конкретного запроса. Я бы рекомендовал выбирать каждый столбец по имени.
Всегда выбирайте col1, col2 и т. д. В представлении. Между двумя известными мне методами нет разницы в эффективности, но использование select * может быть опасным. Если вы измените определение представления, добавив новые столбцы, вы можете сломать программу, используя «select *», тогда как выбор предопределенного набора столбцов (даже всех из них с именами) по-прежнему будет работать.
Думаю, все зависит от того, что делает оптимизатор запросов.
Если я хочу получить каждую запись в строке, я обычно использую опцию «SELECT * ...», так как тогда мне не нужно беспокоиться, если я изменю базовую структуру таблицы. Кроме того, для тех, кто поддерживает код, вид «SELECT *» говорит им, что этот запрос предназначен для возврата каждого столбца, тогда как перечисление столбцов по отдельности не передает того же намерения.
НИКОГДА, НИКОГДА НЕ ИСПОЛЬЗУЙТЕ «ВЫБОР *» !!!!
Это главное правило разработки запросов!
Для этого есть несколько причин. Один из них заключается в том, что если в вашей таблице есть только три поля, и вы используете все три поля в коде, который вызывает запрос, есть большая вероятность, что вы добавите больше полей в эту таблицу по мере роста приложения, и если ваш запрос select * предназначался только для возврата этих 3 полей для вызывающего кода, тогда вы извлекаете гораздо больше данных из базы данных, чем вам нужно.
Другая причина - производительность. При разработке запросов не думайте о повторном использовании так, как эта мантра:
ПРИНИМАЙТЕ ВСЕ, ЧТО СМОЖЕТЕ ЕСТЬ, НО ЕСТЬ ВСЕ, ЧТО ЕСТЬ.
Единственный раз, когда у вас может возникнуть соблазн использовать "select *", это внутри exists (), но не делайте этого! Вместо этого используйте "выберите 1".
@Even Mien: Это зависит от реализации. Некоторые СУБД знают, как оптимизировать SELECT * внутри предиката EXISTS(), поэтому он может быть даже более эффективным, чем SELECT 1. Единственный способ узнать usre - это протестировать вашу марку и версию.
Выбрать * - плохая практика программирования. Это так же может привести к поломке, как и спасти вещи от поломки. Если вы запрашиваете только одну таблицу или представление, то повышения эффективности может не быть (хотя это возможно, если вы не собираетесь использовать все поля). Если у вас есть внутреннее соединение, то у вас есть как минимум два поля, возвращающих одни и те же данные (поля соединения), и, таким образом, вы тратите сетевые ресурсы на отправку избыточных данных обратно в приложение. Сначала вы этого не заметите, но по мере того, как наборы результатов становятся все больше и больше, у вас скоро будет сетевой конвейер, который заполнен, и в этом нет необходимости. Я не могу придумать ни одного случая, когда select * вам что-нибудь принесет. Если добавлен новый столбец, и вам не нужно переходить к коду, чтобы что-то с ним сделать, то этот столбец не должен возвращаться вашим запросом по определению. Если кто-то отбросит и воссоздает таблицу со столбцами в другом порядке, то все ваши запросы будут содержать неверную информацию или будут давать плохие результаты, например, указание цены в поле номера детали в новой записи.
Кроме того, можно быстро перетащить имена столбцов из обозревателя объектов, так что это просто лень, а не эффективность в кодировании.
По производительности - посмотрите план запроса (разницы не должно быть).
По ремонтопригодности. - всегда предоставляйте список полей (это относится и к INSERT INTO).
Просто чтобы прояснить момент, который уже высказали несколько человек, причина неэффективности Select * заключается в том, что должен быть первоначальный вызов БД, чтобы точно узнать, какие поля доступны, а затем второй вызов, когда запрос выполняется с использованием явные столбцы.
Не стесняйтесь использовать Select * при отладке, выполнении случайных запросов или на ранних стадиях разработки запроса, но как только вы узнаете свои требуемые столбцы, укажите их явно.
По-разному. Наследование представлений может быть удобным и простым в обслуживании (SQL Anywhere):
create view v_fruit as select F.id, S.strain from F key join S;
create view v_apples as select v_fruit.*, C.colour from v_fruit key join C;
Это очень хороший пример, когда SELECT view. * FROM view на самом деле является хорошей практикой. Причина в том, что у нас может быть множество фруктов, было бы кошмаром меняться каждый раз, когда изменяется наш родительский класс, поэтому я согласен с этим подходом, однако я не знаю, будет ли это хорошей практикой, если есть это некий уровень отчетности поверх этих фруктов, конечно, предполагая, что нам всегда будут нужны все столбцы из v_fruit
Кроме того, если по какой-то причине имя столбца добавляется в v_fruit, но такое же имя уже существует в любом из v_apples, v_pears и т. д., Мы получим ошибку во время запроса, я знаю, что это проблема дизайна, но это определенно потенциальный риск, есть мысли, как с этим справиться?
select
column1
,column2
,column3
.
.
.
from Your-View
это больше оптимизатор, чем Использование
select *
from Your View
Дубликат По какой причине не использовать select *?