Число столбцов возвратилось, влияют на скорость запроса?

Конечно. Лучше назовите столбцы, которые хотите получить.

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

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

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

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

Если вы действительно хотите использовать *, укажите таблицу, из которой вы хотите, чтобы все столбцы из , например SELECT Person. * FROM Person ...

Это сократит количество возвращаемых данных и сделает их более удобочитаемыми.

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

SELECT Id, Forename, Surname
FROM Person
WHERE PersonName Like(‘%frank%’)

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

SELECT *
FROM Person
WHERE PersonName Like(‘%frank%’)

единственный раз, когда я использую « select * », на самом деле не является событием, а конкретно « select * »

:

select count (*) из таблицы

не то же самое, что

выбрать количество (ID) из таблицы

первый возвращает количество строк в таблице
но второй возвращает количество строк со значением NOT NULL ID.

тонкое различие, но его стоит запомнить.

Да, это так. Обычно:

• С сервера базы данных необходимо передать больше данных
• Сервер базы данных должен получить больше данных

Вы не должны использовать select *

Учтите, что в дополнение к другим ответам SELECT * вернет данные из всех таблиц в запросе. Начните добавлять другие таблицы через JOIN, и вы начнете видеть то, чего не хотите видеть.

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

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

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

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

Я бы ответил на этот вопрос о том, почему использование конструкции «Select *» не является предпочтительным.

По моему опыту, выбор 3 столбцов вместо выбора * в 3 столбцах таблица может не оказывать заметного влияния на производительность, но по мере того, как таблицы становятся больше и шире, вы заметите разницу в производительности.

Как правило, в любой ситуации вы не должны использовать

SELECT * FROM TABLE

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

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

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

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

Обратите внимание на следующий пример из руководства по концепциям Oracle:

Формат и размер строки Oracle сохраняет каждый строка таблицы базы данных, содержащая данные для менее чем 256 столбцов как один или несколько рядов. Если вся строка могут быть вставлены в отдельные данные блок, то Oracle сохраняет строку как один рядный кусок. Однако если все данные строки не могут быть вставлены в единый блок данных или если обновление до существующая строка заставляет строку перерастет свой блок данных, тогда Oracle сохраняет строку, используя несколько строк куски. Блок данных обычно содержит только один кусок для каждого ряда. когда Oracle должен хранить строку более чем в один рядный кусок, он прикован цепью поперек несколько блоков.

Когда в таблице больше 255 столбцы, строки с данными после 255-й столбец скорее всего будет связан в одном блоке. Это называется внутриблочная цепочка. Цепной ряд части соединяются вместе с помощью ряды штук. С внутриблоковым цепочка, пользователи получают все данные в том же блоке. Если строка подходит блокировка, пользователи не видят эффекта в производительности ввода-вывода, потому что никаких дополнительных Операция ввода-вывода требуется для получения остальная часть строки.

ОДНАКО: если столбцов 400, я готов поспорить, что большинство строк не поместятся в одном блоке и, следовательно, вы увидите намного больше 'последовательное чтение файла db' чем обычно требуется. Также я помните, что Стив Адамс (или кто-то давно) упомянув, что существует дополнительная стоимость доступа к колонке "дальше по списку" - извините, не надо есть эта ссылка.

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

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

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

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

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

• Что делать, если в будущем вы решите добавить столбец TEXT или BLOB, который будет использоваться для конкретный запрос? Ваш SELECT * вернет дополнительные данные независимо от того, нужны они вам или нет.
• Что, если вы переименуете столбец? Ваш SELECT * всегда будет работать, но полагающийся код будет сломан.

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

Однако следует помнить о том, что некоторые механизмы SQL (MS-SQL точно) будет кэшировать select *, поэтому, если вы используете подготовленный оператор, представление или хранимую процедуру, у которых он есть, и изменяете схему таблицы, он не улавливает изменение, если представление или sp не будет перекомпилировано, так что - хорошая причина избегать этого, если вы не выполняете эти запросы динамически.

И, конечно, это зависит от ядра базы данных,

SELECT * обычно никогда не бывает хорошей идеей. Возможно, это не сильно замедлит загрузку вашей СУБД, но, вероятно, приведет к тому, что по сети будет передаваться больше данных, чем вам нужно.

Однако, это, вероятно, будет сведено на нет из-за использования LIKE '% frank% ', которое в основном не индексируется и приведет к полному сканированию таблицы.

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

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

select x,y,z from table where name = 'frank'

Если вы хотите получить еще и франклин, используйте:

select x,y,z from table where name like 'frank%'

Оба они смогут использовать индекс для столбец имени, "% frank%" не будет.