Который более быстр/лучший? ВЫБЕРИТЕ * или ВЫБЕРИТЕ column1, colum2, column3, и т.д.

Когда вы объявляете ссылочную переменную (т. е. объект), вы действительно создаете указатель на объект. Рассмотрим следующий код, в котором вы объявляете переменную примитивного типа int:

int x;
x = 10;

В этом примере переменная x является int, и Java инициализирует ее для 0. Когда вы назначаете его 10 во второй строке, ваше значение 10 записывается в ячейку памяти, на которую указывает x.

Но когда вы пытаетесь объявить ссылочный тип, произойдет что-то другое. Возьмите следующий код:

Integer num;
num = new Integer(10);

Первая строка объявляет переменную с именем num, но она не содержит примитивного значения. Вместо этого он содержит указатель (потому что тип Integer является ссылочным типом). Поскольку вы еще не указали, что указать на Java, он устанавливает значение null, что означает «Я ничего не указываю».

Во второй строке ключевое слово new используется для создания экземпляра (или создания ) объекту типа Integer и переменной указателя num присваивается этот объект. Теперь вы можете ссылаться на объект, используя оператор разыменования . (точка).

Exception, о котором вы просили, возникает, когда вы объявляете переменную, но не создавали объект. Если вы попытаетесь разыменовать num. Перед созданием объекта вы получите NullPointerException. В самых тривиальных случаях компилятор поймает проблему и сообщит вам, что «num не может быть инициализирован», но иногда вы пишете код, который непосредственно не создает объект.

Например, вы можете имеют следующий метод:

public void doSomething(SomeObject obj) {
   //do something to obj
}

В этом случае вы не создаете объект obj, скорее предполагая, что он был создан до вызова метода doSomething. К сожалению, этот метод можно вызвать следующим образом:

doSomething(null);

В этом случае obj имеет значение null. Если метод предназначен для того, чтобы что-то сделать для переданного объекта, целесообразно бросить NullPointerException, потому что это ошибка программиста, и программисту понадобится эта информация для целей отладки.

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

/**
  * @param obj An optional foo for ____. May be null, in which case 
  *  the result will be ____.
  */
public void doSomething(SomeObject obj) {
    if(obj != null) {
       //do something
    } else {
       //do something else
    }
}

Наконец, Как определить исключение & amp; причина использования Трассировки стека

159
задан 8 revs, 5 users 52% 13 April 2016 в 04:35
поделиться

45 ответов

Одна причина, что выбор определенных столбцов лучше, состоит в том, что он повышает вероятность, что SQL Server может получить доступ к данным из индексов вместо того, чтобы запросить данные таблицы.

Вот сообщение, которое я записал об этом: запросы Select настоящей причины являются плохим индексным покрытием

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

163
ответ дан 2 revs, 2 users 71% 23 November 2019 в 21:36
поделиться

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

  • Вы знаете порядок, если необходимо индексировать числом, или если драйвер ведет себя забавный на значениях блоба, и Вам нужен определенный порядок
  • , Вы только читаете поля, в которых Вы нуждаетесь, если необходимо когда-либо добавлять больше полей
  • , Вы получаете ошибку SQL, если Вы пишете c орфографическими ошибками или переименовываете поле, не пустое значение от recordset/row
  • можно лучше считать то, что продолжается.
0
ответ дан Erik 23 November 2019 в 21:36
поделиться

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

в конечном счете лучший план состоит в том, чтобы выбрать определенные столбцы.

0
ответ дан siculars 23 November 2019 в 21:36
поделиться

Также помните об изменениях. Сегодня, Выбор * только выбирает столбцы, в которых Вы нуждаетесь, но завтра он может также выбрать это varbinary (МАКС) столбец, который я только что добавил, не говоря Вам, и Вы теперь также получаете все 3,18 гигабайта Двоичных данных, который вчера не был в таблице.

0
ответ дан Michael Stum 23 November 2019 в 21:36
поделиться

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

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

0
ответ дан DamienG 23 November 2019 в 21:36
поделиться

Абсолютно определите столбцы, которые Вы хотите ВЫБРАТЬ каждый раз. Нет никакой причины не к, и повышение производительности определенно стоит того.

Они никогда не должны были давать опцию "ВЫБРАТЬ *"

0
ответ дан cazlab 23 November 2019 в 21:36
поделиться

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

3
ответ дан BrewinBombers 23 November 2019 в 21:36
поделиться

Определение списка столбцов обычно наилучший вариант, потому что Ваше приложение не будет затронуто, если кто-то добавит/вставит столбец к таблице.

10
ответ дан ilitirit 23 November 2019 в 21:36
поделиться

Определение имен столбцов определенно быстрее - для сервера. Но если

  1. производительность не является большим выпуском (например, это - база данных содержания веб-сайта с сотнями, возможно, тысячами - но не миллионы - строк в каждой таблице); И
  2. Ваше задание должно создать много маленьких, подобных приложений (например, направление общественности управляемые содержанием веб-сайты) использование общих основ, вместо того, чтобы создать сложное одноразовое приложение; И
  3. гибкость важна (большая настройка схемы дб для каждого сайта);

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

я знаю, что гуру DB собираются ненавидеть меня за это - идут вперед, проваливают меня - но в моем мире, время разработчика недостаточно, и циклы ЦП в изобилии, таким образом, я корректирую соответственно, что я сохраняю и что я трачу впустую.

7
ответ дан Herb Caudill 23 November 2019 в 21:36
поделиться

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

4
ответ дан Yann Ramin 23 November 2019 в 21:36
поделиться

определенно определяя столбцы, потому что SQL Server не должен будет делать поиска на столбцах для получения по запросу их. Если Вы определяете столбцы, то SQL может пропустить тот шаг.

3
ответ дан Nick Berardi 23 November 2019 в 21:36
поделиться

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

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

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

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

3
ответ дан Alexandre Brasil 23 November 2019 в 21:36
поделиться

Выбор одинаково эффективен (с точки зрения скорости), если Вы используете * или столбцы.

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

то, Что действительно имеет значение с точки зрения производительности, является планом выполнения, который в свою очередь зависит в большой степени от Вашего оператора Where и количества СОЕДИНЕНИЯ, ВНЕШНЕГО ОБЪЕДИНЕНИЯ, и т.д.

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

2
ответ дан Jorge Córdoba 23 November 2019 в 21:36
поделиться

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

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

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

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

, Таким образом, правило должно быть: при необходимости во всех полях используйте *, если Вы нуждаетесь в только подмножестве, называете их явно.

2
ответ дан user9385 23 November 2019 в 21:36
поделиться

Это зависит от версии Вашего сервера БД, но современные версии SQL могут кэшировать план так или иначе. Я сказал бы, идут с тем, что является самым удобным в сопровождении с Вашим кодом доступа к данным.

1
ответ дан Keith 23 November 2019 в 21:36
поделиться

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

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

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

1
ответ дан dpollock 23 November 2019 в 21:36
поделиться

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

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

1
ответ дан Mark 23 November 2019 в 21:36
поделиться

Для прибавления к тому, что все остальные сказали, если все столбцы, которые Вы выбираете, включены в индекс, Ваш набор результатов вытянут от индекса вместо того, чтобы искать дополнительные данные из SQL.

1
ответ дан Mike 23 November 2019 в 21:36
поделиться

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

1
ответ дан Mark Etable 23 November 2019 в 21:36
поделиться

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

Поэтому при использовании всех данных попробуйте ВЫБОР * за простоту (предположите иметь много столбцов и делать, СОЕДИНЕНИЕ... запрашивают, может стать ужасным). Тогда - мера. Сравните с запросом с именами столбцов, перечисленными явно.

не размышляют о производительности, мера это!

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

3
ответ дан Paweł Hajdan 23 November 2019 в 21:36
поделиться

Учитывая [1 127] Ваш спецификация, что Вы выбор всех столбцов, существует мало различия в это время . Поймите, однако, что схемы базы данных действительно изменяются. Если Вы используете SELECT * , Вы собираетесь получить любые новые столбцы, добавленные к таблице, даже при том, что, по всей вероятности, Ваш код не готов использовать или представить те новые данные. Это означает представление системы неожиданной производительности и изменениям функциональности.

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

  1. Read от базы данных
  2. Отправленный через сеть
  3. Собранный в Ваш процесс
  4. (для технологий типа ADO) Сохраненный в таблице данных, в оперативной памяти
  5. Проигнорированный и отброшенный/, собрал "мусор"

, Объект № 1 имеет много скрытых затрат включая устранение некоторого потенциального закрывающего индекса, вызывая загрузки страницы данных (и перегрузка кэша сервера), подвергаясь строке / страница / блокировки таблицы, которых можно было бы иначе избежать.

Баланс это против потенциальных сбережений определения столбцов по сравнению с * и единственных потенциальных сбережений:

  1. Программист не должен пересматривать SQL для добавления столбцов
  2. , сетевой транспорт SQL меньше / быстрее
  3. синтаксический анализ запроса SQL Server / время проверки
  4. кэш плана запросов SQL Server

Для объекта 1, действительность - то, что Вы собираетесь добавить / код изменения для использования любого нового столбца, который Вы могли бы добавить так или иначе, таким образом, это - промывка.

Для объекта 2, различие достаточно редко для продвижения Вас в различный размер пакета или количество сетевых пакетов. Если Вы переходите к сути дела, где время передачи SQL-оператора является преобладающей проблемой, вероятно, необходимо уменьшить уровень операторов сначала.

Для объекта 3, нет НИКАКИХ сбережений, поскольку расширение * должно произойти так или иначе, что означает консультироваться со схемой таблицы (таблиц) так или иначе. Реалистично, список столбцов понесет те же расходы, потому что они должны быть проверены против схемы. Другими словами, это - полная промывка.

Для объекта 4 при определении определенных столбцов кэш плана запросов мог стать больше, но [только 1 133], если Вы имеете дело с различными наборами столбцов (который не является тем, что Вы определили). В этом случае Вы действительно хотите различные записи кэша, потому что Вы хотите различные планы по мере необходимости.

Так, это все снижается из-за способа, которым Вы определили вопрос к упругости проблемы перед лицом возможных модификаций схемы. При записи этой схемы в ROM (это происходит), то * совершенно приемлемо.

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

Мой совет состоит в том, что Вы должны ВСЕГДА ВЫБИРАТЬ определенные столбцы . Помните, что Вы становитесь хорошими в том, что Вы действительно много раз, так просто привыкаете делать его правильно.

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

57
ответ дан IDisposable 23 November 2019 в 21:36
поделиться

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

Не то чтобы перечисление столбцов в SQl server было трудным или даже отнимало много времени. Вы просто перетаскиваете их из браузера объектов (можно получить все за один раз, перетащив из слова columns). Наносить постоянный удар по производительности вашей системы (потому что это может уменьшить использование индексов и потому что отправка ненужных данных по сети стоит дорого) и увеличивать вероятность возникновения неожиданных проблем при изменении базы данных (иногда добавляются колонки, которые вы не хотите, чтобы пользователь видел, например) только для того, чтобы сэкономить менее минуты времени разработки, - это недальновидно и непрофессионально.

1
ответ дан 23 November 2019 в 21:36
поделиться

SELECT * - плохая практика, даже если запрос не передается по сети.

  1. Выборка большего количества данных, чем нужно, делает запрос менее эффективным - серверу приходится считывать и передавать дополнительные данные, что занимает время и создает ненужную нагрузку на систему (не только на сеть, как уже говорилось, но и на диск, процессор и т.д.). Кроме того, сервер не может оптимизировать запрос так хорошо, как мог бы (например, использовать покрывающий индекс для запроса).
  2. Через некоторое время структура вашей таблицы может измениться, поэтому SELECT * вернет другой набор столбцов. Таким образом, ваше приложение может получить набор данных неожиданной структуры и сломаться где-то внизу. Явное указание столбцов гарантирует, что вы либо получите набор данных с известной структурой, либо получите явную ошибку на уровне базы данных (например, "столбец не найден").

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

6
ответ дан 23 November 2019 в 21:36
поделиться

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

2
ответ дан 23 November 2019 в 21:36
поделиться

Вы действительно должны выбирать только те поля, которые вам нужны, и только необходимое количество, то есть

SELECT Field1, Field2 FROM SomeTable WHERE --(constraints)

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

4
ответ дан 23 November 2019 в 21:36
поделиться

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

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

Если у вас есть имена, перечисленные явно, то найти каждую ссылку на этот столбец - во всех ваших хранимых процедурах, представлениях и т. Д. - просто. Просто создайте дамп скрипта CREATE для вашей схемы БД и выполните текстовый поиск по нему.

4
ответ дан 23 November 2019 в 21:36
поделиться

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

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

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

34
ответ дан 23 November 2019 в 21:36
поделиться

Результат слишком велик. Генерация и отправка результата от механизма SQL клиенту выполняется медленно.

Клиентская сторона, являясь общей средой программирования, не предназначена и не должна быть предназначена для фильтрации и обработки результатов (например, предложение WHERE, предложение ORDER), поскольку количество строк может быть огромным (например, десятки миллионов ряды).

2
ответ дан 23 November 2019 в 21:36
поделиться

Есть четыре большие причины, по которым select * - это плохо:

  1. Самая важная практическая причина заключается в том, что он заставляет пользователя волшебным образом узнать порядок, в котором столбцы будут возвращены. Лучше быть явным, что также защитит вас от изменения таблицы, которая прекрасно переходит в ...

  2. Если имя столбца, которое вы используете, изменяется, лучше поймать его на раннем этапе (в момент вызова SQL) а не когда вы пытаетесь использовать столбец, который больше не существует (или имя которого было изменено и т. д.)

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

  4. Если вы выполняете передачу по сети (или даже если это не так), столбцы, которые вам не нужны, просто бесполезны.

30
ответ дан 23 November 2019 в 21:36
поделиться

То, что сказали все выше, плюс:

Если вы стремитесь к читаемому сопровождаемому коду, делайте что-то вроде:

SELECT foo, bar FROM widgets;

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

1
ответ дан 23 November 2019 в 21:36
поделиться
Другие вопросы по тегам:

Похожие вопросы: