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

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

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

SELECT *

Против 

SELECT item1, item2, etc.
5 3
sql performance overhead

5 ответов:

SELECT * FROM...

И 

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

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

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

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

Другие так вопросы на ту же тему...

9

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

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

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

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

2

EDIT: если вы говорите о подстановочной карте asterisk, как в Select * From ..., то смотрите другие ответы...

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

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

 Where Name Like '%ing'

Тогда нет никакого способа обойти индекс в поле имени, чтобы найти узлы, которые конец в "Инге".

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

Where Name like 'Donald%'

Тогда оптимизатор все еще может использовать индекс для столбца name, и запрос все еще является SARG-способным

1

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

insert into mytable values(1,2)

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

0

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

0