Вопросик

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

Ну данных больше в localhost будет гоняться, ещё что?

Еще данных с диска будет больше читаться. Больше памяти тратится в программе, особенно если есть блоб-поля или большие тексты.

Вообще select * считается говнокодом, если нужны не все поля.

не всегда: если логика построена на самом sql и вместо вещественной таблицы - view, то для фронта вполне оправданно не замарачиваться на тонкости, вернее даже обязательно для унификации логики.

С чего бы не всегда? Унификация разве не интерфейсом модели достигается? Таким образом модель знает какие поля нужны, подкапотные вопросы ты инкапсулируешь там. У тебя же пример из разряда «нахер заморачиваться и так сойдет». Даже если нужны все — перечисляй явно (проперти модели).

Это когда мозг застрял в MVC.

А если застрял не в мвц, то? Все так же «нахер заморачиваться и так сойдет».

Ты не совсем понял. Современные MVC легко упрощаются до VC, где функции MV вполне реалзуются средствами самой СУБД, причем любой реляционной. Т.е. само понятие activerecord в коде frontend'a теряет свой смысл. И тогда тебе действительно достаточно и нужно только select *. Любое нагромождение своего кода\фреймворка вокруг задач самой СУБД неминуемо приведет к повторению алгоритмов реализации DSL'а в виде устаканенного SQL. А это усложнение в 100500 раз, т.к. столько человекочасов на любой дурацкий проект тратить не имеет смысла. Другими словами, любая современная реляционная SQL СУБД может мимикрировать под NoSQL БД.

No offence же)

Понятно, что теоретически больше, но главный вопрос *насколько* больше и стоит ли заморачиваться. Блобов нет, сайт не миллион пользователей, но планируется до 10000. Нужны тесты общей разницы в select * и без *. Делать такие тесты не совсем просто. Интересует реальная разница в попугаях )

Ты снова про «и так сойдет». Я вижу твои аргументы, но есть и обратные.

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

Ок, велосипед, без моделей, прямыми запросами, стОит заполнять «структуры» выборкой из бд явно перечисляя поля-проперти (как пример, актуальны для ТС пыховые PDO::FETCH_INTO, PDO::FETCH_OBJ). Приложение просто обязано манипулировать готовыми кучками данных без всего лишнего (это те же «MVC упрощаются до VC»). И даже вьюху (бд) стОит выбирать не звездочкой т.к. данные из бд должны передаваться в приложение настолько явно, насколько это возможно.

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

Померять то я могу, хотел услышать реальные примерны, на личном опыте

Померять то я могу, хотел услышать реальные примерны, на личном опыте

А толку? Зависит от общего числа полей и их размера, а также от числа тех полей, которые выводятся явно (когда без *) и их размера.

Также зависит от размеров выборки и объёма ОЗУ.

От скорости диска.

Возможно, от используемой СУБД и модели.

Разных комбинаций может быть чуть меньше, чем бесконечно. Поэтому если у кого-то на другой СУБД с другими данными, другим объёмом памяти и т. д. было как-то так, то это не значит, что и в твоём случае будет так же. Остаётся только тестить.

Есть проект, в котором несколько таблиц с не менее 100к записей на каждую и обновление информации я стараюсь делать как можно более точным запросом (ORM, get(id)), потому что выборка даже по составному ключу уже заметно медленнее работает, а если выбрать всё и потом фильтровать — это будет просто ад.

Код пишется, чтобы его человеку потом понять. Открыл код, а там «SELECT * FROM foo;» и иди трать время, отвлекайся, смотри, что за таблица и что за поля в ней. А если написано «SELECT name, address FROM foo», то и ходить никуда не надо, сразу знаешь, что прилетит и что с этим делать.

Ну данных больше в localhost будет гоняться, ещё что?

А вдруг не localhost?

в localhost

Если у тебя БД и приложение на одной машине — не заморачивайся.

Этот вопрос похож на «нужны ли в БД другие индексы, кроме primary key, и другой пользователь, кроме root@localhost?» примерно с таким же ответом. Дома, на локалхосте, с маленькими таблицами и лёгкими, простенькими запросами, для одного единственного девелопера с одним единственным нетребовательным и снисходительным пользователем (самим собой) - да плевать! Но как только задача становиться чуть менее тривиальной - без них не обойтись. Звёздочка собой скрывает чувствительные поля, поля с разных таблиц с тем же названием и, возможно, недавно поломанную схему. С ней не станет работать запросы для таблиц, где есть ограничения по доступу к её столбикам. В конечном итоге, звёздочка не даёт возможностей и ясности, а наоборот - сильно ограничивает и запутывает, так что её лучше не использовать.

Насколько это влияет на производительность?

В контексте mysql не влияет. А если взять column oriented databases, как например vertica, то влияет. В обычных реляционных БД данные и все построенные индексы указывают на конкретные строки таблицы, если нашел строку то одинаково что считать все колонки, что только одну. В column oriented databases каждая колонка имеет свои индексы и выборка из множества колонок похоже на запрос к множеству таблиц в обычно БД.

Почему перечисляют:

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

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