Который более быстр/лучший? ВЫБЕРИТЕ * или ВЫБЕРИТЕ 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
поделиться

35 ответов

Одна причина, что выбор определенных столбцов лучше, состоит в том, что он повышает вероятность, что 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
поделиться

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

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

Основным различием между этими двумя является объем данных, переданный назад и вперед. Любые аргументы о разнице во времени существенно испорчены в том "выборе *" и "выборе col1..., colN" результат в том же объеме относительной работы, выполненной механизмом DB. Однако передача 15 столбцов за строку по сравнению с 5 столбцами за строку является различием на 10 столбцов.

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

Ну, это действительно зависит от Ваших метрик и цели:

  1. , Если Вы имеете 250 столбцов и хотите (действительно) выбрать их всех, используйте выбор *, если Вы хотите возвратиться домой тот же день:)
  2. , Если для Вашего кодирования нужны гибкость и нуждающаяся таблица, является маленьким, снова, выберите *, помогает Вам кодировать быстрее и поддержать его легче.
  3. , Если Вы хотите устойчивую разработку и производительность:
    • пишут Ваши имена столбцов, если они, только некоторые, или
    • пишут инструмент, который позволяет Вам легко выбрать/генерировать свои имена столбцов

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

И наконец, что не менее важно, как Вы хотите добавить или удалить столбец в таблице для влияния на код или его обслуживание?

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

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

/Allan

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

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

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

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

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

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

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

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

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

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

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

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

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

Это особые случаи как представления или хранимые процедуры, где Вы хотите, чтобы изменения в базовых таблицах распространили, не будучи должен пойти и изменить каждое представление, и сохранили proc, который использует таблицу. Даже тогда это может вызвать проблемы само, как в случае, где у Вас есть два представления, к которым присоединяются. Изменения базовой таблицы и теперь представление неоднозначно, потому что обе таблицы имеют столбец с тем же именем. (Обратите внимание, что это может произойти любое время, Вы не квалифицируете все свои столбцы с префиксами таблицы). Даже с префиксами, если у Вас есть конструкция как:

ВЫБОР A. , B. - у Вас могут быть проблемы, где клиент теперь испытывает затруднения при выборе правой стороны поля.

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

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

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