vs


Вопросы:
1) Если два эти запроса выполняются не для получения данных, а для подсчета выбранных строк, то что именно мы теряем, если средний размер ряда 20 Кб, а количество выборки 12 тыс. строк?
2) Памяти больше сжирается? Корректно ли утверждать, что первый запрос требует на 240 Мб больше, чем второй? Чую, что, скорее всего нет, но утверждать что-либо у меня нет оснований.
3) Есть ли у первого запроса из-за звездочки потеря в производительности и если да, то о каких % потерь в скорости идет речь: 5%, 20%, 50%, в 2, 5, 10 раз медленнее?
4) Какие вообще сжираются ресурсы сервером при выполнении select'а до получения самих данных?

vkle1) Если два эти запроса выполняются не для получения данных, а для подсчета выбранных строк, то что именно мы теряем

Вероятно, мозг. Потому как для подсчёта количества строк рекомендуют использовать функцию count(), специально для этого предназначенную. СУБД по барабану, как будут использованы отданные им записи.

Эта тема не про решение какой-то конкретной задачи из ежедневной практики на получение количества записей.
В практике все задачи уже решены.
Этот пример искусственно создан для иллюстрации.
Вопрос стоит в понимании принципов работы со звездочкой * по сравнению с фиксированным списком полей.

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

Я понял, что сформулировал задачу неудачно.
Делаю второй подход к формулированию.

Пусть есть таблица.


и для учебных целей мы заполняем её 1 млн. записей, где в каждое поле tit пишем 32 Кб текста.
Затем выполняем два запроса на клиенте, но данные НЕ фетчим данные.



Насколько я понимаю, первый запрос грузит сервер существенно больше, чем второй.
Вот я и хочу узнать ПРИНЦИПЫ что там примерно происходит, чтобы руководствуясь этими принципами можно было бы принимать более мудрые решения, когда звездочка погоды не делает, а когда замена звездочки на id может привести к сильной экономии.
Например, у меня есть внутренне ощущение, что в данном примере объем записанного текста, хоть 1кб, хоть 32 кб, на запрос со звездочкой не влияют, но я не могу это объяснить.

Блин, вижу, что моя вторая попытка сформулировать задачу тоже провалилась... (((

MasterZivподумай лучше сам, что СУБД должна сделать, чтобы выполнить оба запроса.

Вопрос: Есть где-нибудь в интернете какая-нибудь статья или ещё лучше картинка (инфографика) где не профессорским, а более-менее простым языком перечисляются последовательности (примерный стратегический алгоритм) действий, которые происходят внутри сервера при выполнении обычного селекта? Или все, что там происходит настолько сложно, что больше похоже на русскую рулетку?

MasterZivа невозможно изолировать выполнение запроса от стадии передачи данных клиенту.
Вопрос: Неужели не существует никакой экономии от того, что клиент не стал фетчить данные с сервера, а только выполнив select * запрос, просто стал выполнять другие запросы? Неужели с точки зрения сервера не существует разницы, если select * выбрал 10 тыс. строк, но клиент сфетчил первые 50, а остальные 9950 фетчить не стал, а просто стал выполнять какие-то другие запросы? Я в этом смысле имел ввиду изоляцию стадии выборки и стадии транспорта...

вадяну а если запрос сделан и закрыт - то что не забрано с сервера, серверу пофиг, и он этот объём держит в кэше минимум времени...

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

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

2) что именно складывается в кеш?




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

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

Но неужели в третьем селекте в кеш копируется только список айдишников-интов? Если нет, то тогда список из интов и колонки а? А если так и у нас в каждой записи в колонке а хранится по 32 кб данных, то все эти 32 Кб кидаются в кеш? или может быть все таки в кеш кидается ссылка (то есть инт), а 32 кб достаются только в момент фетчинга записи??

вадяну вот я боюсь предлагать тебе ссылку, вдруг опять будешь ругаться....
http://habrahabr.ru/post/41166/

статью прочитал
по моей теме со звездочкой она ничего не проясняет, к сожалению...

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

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

неприятная новость в статье следующая: перед выполнением запроса сервер не знает о размере получившейся выборки... то есть не совсем понятно что происходит для запросов типа select * from t where id = 100500; Видимо как раз для таких случаев вы используете SQL_SMALL_RESULT типа как тут 18351614

итого:
1) из статьи я так и не понял в чем разница при работе с кешем для select * vs select id
2) не понял для select id from t where a like '%1%' && b like '%2%' в кеш достаются все поля таблицы, только id поля или id, a, b поля

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

netwindУ select * конечно же меньше преимуществ в разрезе кеширования, потому что, в общем случае, данных в нем больше и они памяти больше занимают.

Насколько корректно просто сложить размеры полей:
все инты, варчары и тексты по 8 байт
+ все чаты по 1 байту на длину чара
и умножить на количество записей в таблице?

пример




Вопрос: Если в таблице 8 тыс. записей, то сколько кеша запросов схавает запрос select * from t where id = 5;
Ответ: 8 + 6 + 8 + 8 + 1 * 8000 = 31 * 8000 = 248 Кб

Так верно или ошибочно?

автор2) не понял для select id from t where a like '%1%' && b like '%2%' в кеш достаются все поля таблицы, только id поля или id, a, b поля
Достается и хранится весь результат как он есть. То есть, поле id.[/quot]

Блин, опять запутался: в кеше хранятся данные, по которым производится выборка a like '' && b like '' или в кеше все-таки хранятся результаты выборки и если у нас where id = 5, в то кеше будет хранится вся таблица в которой искалось id = 5 или в кеше будет храниться только одна эта запись?

Ну и собственно мы опять вернулись в исходную точку:
когда поступает select * from t where id = 5, то сервер ведь не на винчестере ищет данные, а он сначала их с винчестера читает в память и уже в памяти их "перебирает" для выполнения запроса? и в вашей статье даже есть модификатор SQL_NO_CACHE, который принудительно заставляет эту переборку делать на диске, если изначально известно, что размер выборки огромен.

Так вот если производство выборки на диске задается директивой НО КЕШ, значит обычный ход обработки запроса - это КЕШ
или кеш в котором производится выборка данных и кеш запросов - это два разных типа кеша??
если да, то меня интересует не кеш, в котором хранятся уже выполненные результаты запросов, а кеш, в котором хранятся данные, из которых производится выборка
а ещё точнее меня интересует влияние на этот кеш звездочки в селекте