вадяinnodb_buffer_pool_size = 512M
первый обращение запроса загружает таблицу в эту память, повторный - уже ищет в ней

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

ну и как я уже приводил есть 3 варианта как мне видится:



если по первому селекту понятно, что грузится вся таблица, то по второму и третьему - вопрос: вся или во втором случае только список (id), а втретьем только список (id, a)??

Причина этого вопроса в том, что если и во втором и третьем случае в этот пул будет грузиться ВСЯ таблица, тогда select * вообще ни в чем не проигрывает селектам с перечисленными полями!!!

Alex_Ustinovну, так сказать, просто проверьте, что происходит на самом деле
создайте таблицу, как в вашем примере
до после запросов 2 и 3

смотрите
Show variables like %cache%;

оцените "дельту" Qcache_free_memory
почувствуйте разницу......

Ну и какой мне смысл чувствовать разницу?
Разница - это все рано что температуру мерить у пациента.
Ну понятно, что у одного температура 37 у другого 39 и что дальше?
То, что вы мне предлагаете - это не метод исследования, а игра в поле чудес.

netwindLumix, вас остается только исходники читать оправлять. Все ж прозрачно и понятно.

Нее, сорсы читать не буду.
Игра не стоит свеч.

netwindНу попробуйте вместо Хабра купить на торентах книжку High Performance MySQL

Только что по вашей рекомендации прочитал эту книжку
На торренты даже идти не пришлось, лежит в инете открытой ссылкой
http://moemesto.ru/kristy/file/9626805/OReIlly.High.Performance.MySQL.pdf

вот что я смог взять оттуда полезного, но прямого ответа на свой вопрос я так и не нашел, только косвенные намеки

стр. 81. Избегайте NULL как только возможно
стр. 85. Char всегда обрезает пробелы с обоих концов строки
стр. 87. Text и Blob требуют от 1 до 4 байт для хранения каждой колонки
стр. 87. Никогда не сортируйте по полю с типом Text или Blob
стр. 124. Индексы используются как для поиска, так и для сортировки
стр. 153. Относитесь с подозрением ко всем select *
стр. 154. но select * имеет смысл, если смотреть с точки зрения кодинга по обслуживанию софта
стр. 157. мускул тянет 50К запросов / сек локально и 2К запросов / сек по гигабитной сетке

стр. 159. декомпозиция джоинов на отдельные селекты с клиента дает существенную экономию в хайлоаде

стр. 169. в мускуле in() умный, то есть в других базах in() является аналогом OR и поэтому алгоритмическая сложность линейная, то у мускульного in() за счет сортировки алогоритмическая сложность логарифмическая

стр. 178. Вот в этом параграфе Query Execution Engine должна была располагаться инфа, которую я ищу, но там лишь вода... (((

стр. 299. Для InnoDB опасно хранить данные, если ряд превышает 8 Кб, потому что будет создаваться дополнительная 16КБ пага и она все время будет подтягиваться в пул, как только двигателю понадобится эта запись

стр. 300. На чтение колонок влияет не select *, а where, то есть условия выборки и если запись понадобится, то в пул будут считываться все паги этой записи

стр. 300. Если в записи слишком много больших колонок, то лучше объединить их в одну, иначе на каждую колонку будет создаваться отдельная innodb пага по 16 кб

стр. 313. Если InnoDB потребуется запись, то она будет читать с диска в пул все 16 кб, вне зависимости от select *, причем даже если вес записи 6 интов, то есть 24 байта, все равно будет читать 16 кб

стр. 577. Buffer pool hit rate - соотношение - какой % данных достается из пула, а не из диска

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

но применительно к обсуждаемой теме, если пага записи уже в пуле, то нет никакой разницы select id или select * - все равно в паге хранится вся запись

*

просмотрел доку, тоже нет ответа

https://dev.mysql.com/doc/refman/5.5/en/estimating-performance.html
https://dev.mysql.com/doc/refman/5.5/en/innodb-buffer-pool.html
https://dev.mysql.com/doc/refman/5.5/en/optimizing-innodb-diskio.html
https://dev.mysql.com/doc/internals/en/innodb-page-structure.html

*

Таким образом из книжки понял следующее: единственный перегрев от select * может быть в хранении лишних данных в кеше запросов, тогда как кеш данных (пул) все равно хранит данными пагами по 16 кб и на его нагрузку влияет не select *, а сколько записей потребуется перебрать, чтобы выполнить запрос

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

кеш данных (пул) убивают запросы, выполнение которых требует перебора сразу большого количества данных, то есть запросы без условий и лимитов, а select * тут вообще ни при чем


Alex_Ustinovвы постоянно уводите обсуждение в сторону
этак мне не так а это не эдак.

мой интерес в этой теме довольно узок - понять принципы как влияет список полей в селекте по сравнению с select *

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

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

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

Alex_UstinovПосмотрел на топики с вашим участием, вы оказывается спец в С/С++.
Исходники на офф.сайте лежат в свободном доступе.

Я не буду копаться в сорсах ради получения ответа на этот вопрос.

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

netwindТак что для innodb select id, где id есть primary key, всегда существенно выгоднее select * .

не пойму эту фразу, потому исходя из философии хранения innodb select * уже всегда содержит в себе primary key...

Исходя из книги, которую я прочитал по вашей рекомендации я понял, что вне зависимости от перечисления полей, если движку для обработки запроса понадобится 1000 каких-то записей, то он потянет в пул все страницы этих записей ВНЕ зависимости от select * это или select id

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

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

netwindУпускаете как именно происходит считывание страниц. Желательно таки дочитать книжку, чтобы понимать как это работает все вместе. Как минимум первых 5 глав.

ну вот собственно вот так и разводят всех новичков на форумах...
и меня тоже много лет так разводили в начале моего профессионального пути...

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

ведь это так приятно с умным сказать: ИДИ ЧИТАЙ!!
http://moemesto.ru/kristy/file/9626805/OReIlly.High.Performance.MySQL.pdf

netwindОчевидно, для запросов типа select id_primary ..., select key_value ... where key_value= достаточно считать только некоторые страницы содержащие этот индекс, а primary key или значения столбцов из индекса там уже будут в этих же страницах.
А в случае с select * нужно считать по ссылке дополнительные страницы содержащие остальные поля записи.

а ведь никто из "советчиков" так и не смог сказать, что

select * from t where a like 'some'
проигрывает
select id from t where a like 'some'
в случае, если по полю a объявлен ключ (задан индекс),
но становится таким же неэффективным как
select * , если в запросе появляется поле, которого нет в индексе,
например
select id, b from t where a like 'some'
или select id from t where a like 'some' && b like 'some'