Подстановочный знак SQL:накладные расходы на производительность?

Question

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

Что я имею в виду конкретно:

SELECT *

против.

SELECT item1, item2, etc.

Answer 1

SELECT * FROM...

и

SELECT every, column, list, ... FROM...

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

Разница в следующем:

• дополнительный поиск в sys.columns для решения *
• изменение контракта/подписи при изменении схемы таблицы
• невозможность создания покрывающего индекса.На самом деле, никаких вариантов тюнинга вообще нет.
• необходимо обновить представления, если они не привязаны к схеме
• невозможно индексировать или связать представление с помощью *
• ...и другие вещи

Другие вопросы SO по той же теме...

• В чем причина не использовать select * ?
• Есть ли разница между Select * и Select list для каждого столбца?
• Вопрос SQL-запроса: выберите * из представления или выберите col1, col2… из представления
• «выбрать * из таблицы» и «выбрать colA, colB и т. д. из таблицы» интересное поведение в SqlServer2005

Answer 2

Ты имеешь ввиду select * from ... вместо select col1, col2, col3 from ...?

Я думаю, что всегда лучше дать столбцу имя и получить минимальное количество информации, потому что

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

Если под «подстановочным знаком» вы имеете в виду что-то другое, просто проигнорируйте мой ответ...

Answer 3

РЕДАКТИРОВАТЬ:Если вы говорите о подстановочном знаке звездочки, как в Select * From ... тогда посмотрите другие ответы...

Если вы говорите о подстановочных знаках в предложениях предикатов или других выражениях запроса с использованием оператора Like, (_ , % ) как описано ниже, тогда:

Это связано с тем, влияет ли использование подстановочного знака на то, является ли SQL «SARG-ABLE» или нет.SARGABLE (Search-ARGument-able) означает, могут ли аргументы поиска или сортировки запроса использоваться в качестве входных параметров для существующего индекса.Если вы добавите подстановочный знак в начало аргумента

 Where Name Like '%ing'

Тогда невозможно пройти по индексу поля имени и найти узлы, которые конец в «инг».

Если вы добавите подстановочный знак в конец,

Where Name like 'Donald%' 

тогда оптимизатор по-прежнему может использовать индекс в столбце имени, и запрос по-прежнему поддерживает SARG.

Answer 4

Если вы называете SQL wild car, это *.Это само по себе не подразумевает накладных расходов на производительность.Однако если таблица расширена, вы можете обнаружить, что получаете поля, которые не ищете.В общем, не указывать конкретные поля, которые вы ищете или вставляете, — это плохая привычка.Учитывать

insert into mytable values(1,2)

Что произойдет, если таблица расширится до трех полей?

Answer 5

С точки зрения плана выполнения, возможно, это не требует дополнительной работы.Но если вы извлекаете столбцы, которые вам на самом деле не нужны, между базой данных и вашим приложением используется дополнительная полоса пропускания сети.Также, если вы используете клиентский API высокого уровня, который выполняет некоторую работу с возвращаемыми данными (например, Perl selectall_hashref), то эти дополнительные столбцы приведут к снижению производительности на стороне клиента.Сколько?Зависит от.