Проблема производительности в использовании ВЫБОРА *? [дубликат]

Я соглашаюсь с примерно всеми ответами кроме определенных заявлений о производительности. Если бы Вы на самом деле собираетесь использовать все столбцы в таблице, я обсудил бы ВЫБОР *, версия является каплей быстрее. Вот то, почему:

Возьмите эти два запроса на таблице, где существует уникальный индекс на (идентификатор, x):

SELECT x,y,z,w FROM tab WHERE id='abc' ORDER BY s

SELECT x,y,z,w FROM tab WHERE id='abc' 
AND x in ('a','b','c','d','e','f','g','h',...)
ORDER BY ('a','b','c','d','e','f','g','h',...)

Который быстрее? Если 'x в' пункте называет все значения для x в таблице для идентификатора 'abc' затем, первый запрос, вероятно, быстрее. Теперь давайте переименуем эти поля:

SELECT field_name, field_type, field_offset, field_len
FROM internal_field_catalog
WHERE table_name = 'abc'
ORDER BY field_order

Таким образом, при получении данных, ВЫБОР * позволяет механизму делать (эквивалент) единственный memcpy для перемещения данных строки в набор результатов и при получении полевых данных, это, вероятно, выбрано быстрее.

Все, что я говорю, существует пограничный случай, где ВЫБОР * совершенно полезен и вероятно быстрее. Одна причина Вам, возможно, всегда понадобились бы все столбцы от таблицы, при хранении объектной персистентности в RDBMS (по некоторым причинам). К каждому эмпирическому правилу существует исключение.

Производительность Это всегда будет плохо, если Вам не БУДУТ НУЖНЫ все столбцы. Возврат большего количества данных, чем необходим, отрегулирует базу данных и Вашу пропускную способность LAN / бледную пропускную способность.

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

*Тестирование при внесении изменения схемы весь код, которые используют ВЫБОР * в, должно делаться недействительным, потому что любые тесты, которые Вы пишете для проверки метаданных, должны проверить вывод представления, proc.

*Конечно, принимая Вы имеете в распоряжении тесты как весь хороший DB, который должен иметь Dev :)

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

Самый большой хит производительности ВЫБОРА * оператор - при выполнении запроса, который требует, чтобы Некластеризованный индекс оценил. Даже если некластеризованный индекс будет закрывающим индексом каждого столбца, то SQL будет все еще искать первичный ключ и получать значения от кластерного индекса.

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

Если Ваше встраивание sql в коде затем Ваш должно всегда использовать подробную форму для ясности, не производительность. Для специальных запросов выбор * синтаксис ПО СУЩЕСТВУ не менее эффективен, чем определение имен столбцов, если у Вас нет крупного количества столбцов, которые Вы не были должны, если Вы не денормализовываете.

Я должен понять 1 мысль для использования 2 unlesses в предложении, и все еще habving это имеют смысл!!:)

Если Вы только используете подмножество полей, то различие в производительности может быть существенным. Посмотрите следующий пример, который включает получение 1 411 771 строки от анализа CSCOUT кода Linux.

$ time sh -c "echo 'select * from IDS' | mysql cslinux >/dev/null"
real    0m5.622s
user    0m2.580s
sys     0m0.532s

$ time sh -c "echo 'select EID from IDS' | mysql cslinux >/dev/null"
real    0m4.492s
user    0m0.716s
sys     0m0.096s

Это даже не измеряет влияние производительности на сервер.

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

Например: выберите количество (1) из... по сравнению с избранным количеством (*) от...

В этом примере RDBMS только должен знать, что ему нужны количество первого столбца и ПРОТЯЖНЫЙ ЗВУК, это выключено. В (к сожалению), более общем избранном количестве (*), RDBMS получает список всех столбцов и затем проверяет каждую строку, чтобы определить, допустимо ли это для подсчета (в противоположность проверке только 1-го столбца).

Это работает отлично большую часть времени. Я вполне уверен, большинство систем DB считает Нулевые значения в количестве, но необходимо не упустить это и проверить перед принятием.

YMMV, пусто, где запрещено, и т.д.!

Предположительно, да. Мне искренне говорят на работе, что я никогда не должен использовать ВЫБОР *. На самом деле это находится в нашей политике не использовать его, потому что a) это означает, что существует неоднозначность в том, что используется и что доступно только путем рассмотрения запроса и b) это медленнее, поскольку SQL-сервер должен найти каждый столбец, этому нужно, и возвратите их.

Я никогда не видел доказательства этого, как бы то ни было.

Править: Кроме того, если хранимая процедура будет скомпилирована на сервере и будет использовать ВЫБОР *, когда структура базовой таблицы изменится, предположительно, это не выберет назад недавно представленные столбцы как ВЫБОР компиляций SQL * вниз к отдельным столбцам.

ВЫБЕРИТЕ *, переводится для ВЫБОРА Field1, Field2.... и т.д., прежде чем он будет выполнен так, они - эффективно то же самое. Никакая разница в производительности.

Однако удобочитаемость и maintaiability лучше когда его ИЗБРАННЫЙ Field1, Field2..

Возможно. Это зависит в основном от механизма базы данных, как это хранит материал, сколько строк возвращается, сколько других столбцов, там и размеры других столбцов.

Если Вы используете находящуюся на строке базу данных (т.е. большинство из них), который хранит все столбцы вместе (почти все делают, за исключением БЛОБОВ, которые часто хранятся отдельно, особенно большие), то выполнение ВЫБОРА * оказывает мало влияния на сам сервер - это должно выбрать всю строку так или иначе.

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

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

Существуют, некоторые "столбец основывали" живущие механизмы базы данных - они полностью отличаются - для них, "ВЫБОР *" является общим уничтожителем производительности; обязательно избегайте его. Возможности, если Вы используете один, Вы полностью знаете об этом, хотя (обычно они используются для очень больших datawarehouse приложений).

Для меня основным преимуществом не использования "ВЫБОРА *" является пригодность для обслуживания. Вы не получаете неожиданностей, когда кто-то добавляет дополнительные столбцы к таблице; Ваш запрос "перестал работать быстро", когда кто-то удаляет один из столбцов, Вы использовали. Это делает код большим количеством самодокументирования, поскольку кто-то может небрежно видеть, какие столбцы Вы хотели.

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

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

Производительность, не очень. Это просто немного неуклюже: в таблице, скажем, с 10 столбцами, к которым присоединяются на двух других таблицах или еще больше, особенно с большими наборами результатов, ВЫБОР * может возвратить десятки столбцов, часто с главным образом неиспользованными или даже бесполезными данными. С точки зрения хита на DBMS, не был бы очень, но все эти данные все еще должны переместиться через провод так или иначе; сетевая пропускная способность и последовательные задержки, конечно, складывают. Я видел это непосредственно в средах большого объема. Это определенно имеет значение.

Кроме проблем пропускной способности, можно также столкнуться с неоднозначными называющими столбец проблемами (снимающий неоднозначность, обычно означает удалять ВЫБОР * так или иначе, таким образом, Вы могли бы также сделать это от запуска), и это также полагало, что хорошая практика является явной о потребностях кода в коде; выполнение так помогает большим количеством способов - с отладкой, с сотрудничеством, и т.д.

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

Я лично использую все это время.

Я не знаю о вычислительной производительности, но с точки зрения read/maintain-ability (т.е. Человеческая Производительность), мы не используем выбор * в моем магазине. Все явно выбрано.

Я не DBA, но от того, что я вспоминаю приобретение знаний из нашего DBA, обоснование (по крайней мере, с SQL Server) состоит в том, что алгоритмы кэширования DB не кэшируются '*' запросы хорошо, но если Вы выполните тот же запрос с точными столбцами, указанными многократно, то это будет кэшировать это хорошо.

Я уверен, что более хорошо осведомленный DBA мог вдаваться в точные подробности того, как механизм кэширования работает, но вот почему существует хит производительности.

Примечание: Кэширование производительности только работает, если бы запрос будет выполненным многократно, особенно в маленький период времени, так иначе Вы не видели бы различия в производительности.

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

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

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

Смотрите на это сообщение:

Что причина не состоит в том, чтобы использовать выбор *?

и они:

• Выигрыш в производительности, когда SQL-запрос ограничен по сравнению с вызовом всей строки
• Который является быстрее или лучшим, выберите * или выберите column1 colum2 column3
• Вопрос о SQL-запросе выбирает * из представления или избранного col1 col2 col3 от представления
• Который быстрее, выберите * или выберите column1 column2 и т.д.

При использовании выбора * в соединении затем, Вы автоматически отправляете больше информации, чем Вам нужен becasue, объединяющее поле (поля) повторяется. Это - пустая трата времени обработки и сетевых ресурсов и может вызвать проблемы производительности. Далее не определение полей означает, что Ваше приложение может повредиться, когда новые поля добавляются особенно, если они - поля, которые пользователь не предназначается для наблюдения, но которые являются там для обработки типа БД или аудита. Выбор * во вставке всегда является плохой идеей как где-нибудь вдоль строки некоторый somen, кто менее, чем умен, может на самом деле изменить порядок столбцов в таблице.