Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Стоимость повторных запросов / 25 сообщений из 25, страница 1 из 1
29.08.2015, 20:37:31
    #39039223
Lumix
Lumix
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
Существует ли у mysql какая-нибудь гарантия, что повторные запросы, вызванные рядом всегда выполняются быстрее?

Например

Код: sql
1.
2.
3.
4.
5.
6.
select * from t where t > 15 order by t limit 10;

-- будет ли этот запрос выполнен быстрее из-за того, 
-- что перед этим был выполнен точно такой же??

select * from t where t > 15 order by t limit 10;




Код: sql
1.
2.
3.
4.
5.
6.
7.
select * from t where t > 15 order by t limit 10;
select * from t where t > 10 order by t limit 10;

-- будет ли этот запрос выполнен быстрее из-за того, 
-- что недавно перед этим был выполнен точно такой же??

select * from t where t > 15 order by t limit 10;
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.08.2015, 21:01:29
    #39039225
netwind
netwind
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
Lumix, конечно, же гарантии нет. Но обычно запросы выполняются быстрее.
Помимо query cache, других кешей еще много на разных уровнях.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.08.2015, 01:03:26
    #39039248
miksoft
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
Lumix,

Повторный запрос может и кардинально медленнее оказаться.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.08.2015, 21:10:24
    #39039404
Lumix
Lumix
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
miksoft,

а есть в мускуле какие-нибудь средства влияния на повторные запросы или как выше назвали на query cache или что-то в этом роде?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.08.2015, 21:26:57
    #39039407
miksoft
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
Lumixmiksoft,

а есть в мускуле какие-нибудь средства влияния на повторные запросы или как выше назвали на query cache или что-то в этом роде?query cache регулируется, а больше никаких специальных средств не знаю.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.08.2015, 11:13:19
    #39039606
MasterZiv
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
Lumix,
нет, нет такой гарантии.
причем не только в mySQL.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
03.09.2015, 12:06:13
    #39042288
alex564657498765453
alex564657498765453
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
LumixСуществует ли у mysql какая-нибудь гарантия, что повторные запросы, вызванные рядом всегда выполняются быстрее?

Например

Код: sql
1.
2.
3.
4.
5.
6.
select * from t where t > 15 order by t limit 10;

-- будет ли этот запрос выполнен быстрее из-за того, 
-- что перед этим был выполнен точно такой же??

select * from t where t > 15 order by t limit 10;




Код: sql
1.
2.
3.
4.
5.
6.
7.
select * from t where t > 15 order by t limit 10;
select * from t where t > 10 order by t limit 10;

-- будет ли этот запрос выполнен быстрее из-за того, 
-- что недавно перед этим был выполнен точно такой же??

select * from t where t > 15 order by t limit 10;



будет гарантия что будет второй быстрее первого в среднем. ну тоесть елси раскидать по коду сайта твоего в тупую делать два таких запроса подряд, то в среднем второй будет быстрее выполняться. это если запросы идентичные.
дело в том что кеш результата маркируеться точным запросом.
тоесть если ты напишешь запрос
b=9 AND
а > 10

и запрос
b = 10 AND
a > b

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

твой случай
a > 15

a>10
даже если на поле а индекс, запросы разные даже по результату выполнения.

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

но это всё - это не кеширование результатов запросов, это кеширование самих данных , чтобы не читать с винчестера ... - вцелом, особенно кеширование индекса даёт приличный результат - для этого увеличенная оперативка и выставленные большие размеры на кеши для иннодб
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
03.09.2015, 12:22:05
    #39042328
Cygapb-007
Cygapb-007
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
Интересный способ оптимизации. Мне нравится.

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

А что, второй запрос и правда может выполниться немного быстрее, чем первый (дольше - вряд ли...), поэтому оптимизация - налицо
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
05.09.2015, 16:13:50
    #39043987
Lumix
Lumix
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
alex564657498765453,

а если речь идет о запросах, которые достают конкретные записи в стиле id = 5, id = 12 и т.п. то фантомные остатки выборок из предыдущих запросов реально ускоряют выполнение повторных ПОЛНОСТЬЮ ИДЕНТИЧНЫХ запросов?

какой именно параметр влияет на объем этих фантомных выборок? если например, мы знаем, что одна запись у нас 12 кб, то какой параметр и в какое значение выставить, чтобы можно было "хранить" в фантомных остатках, скажем, 50 записей, которые мы достали через прямое обращение в стиле select * from a where id = 5 ???
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
05.09.2015, 16:28:59
    #39043995
miksoft
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
Lumixкакой именно параметр влияет на объем этих фантомных выборок? если например, мы знаем, что одна запись у нас 12 кб, то какой параметр и в какое значение выставить, чтобы можно было "хранить" в фантомных остатках, скажем, 50 записей, которые мы достали через прямое обращение в стиле select * from a where id = 5 ???Термин "фантомные" несколько странен...
Но есть query_cache_limit и прочие параметры, название которых начинается на query_cache.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
05.09.2015, 16:44:58
    #39044003
Lumix
Lumix
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
miksoft,

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

Если я правильно понял его идею, то он рассказывает об ускорении запросов за счет данных, которые ещё не успел убить сборщик мусора. Именно отсюда появляется понятие фантомной памяти. То есть это как бы русская рулетка. Как повезет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
05.09.2015, 17:01:26
    #39044012
miksoft
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
LumixЕсли я правильно понял его идею, то он рассказывает об ускорении запросов за счет данных, которые ещё не успел убить сборщик мусора. Именно отсюда появляется понятие фантомной памяти. То есть это как бы русская рулетка. Как повезет.Если речь о посте 18103519 , то там речь идет о том, чтобы в кэш InnoDB попали нужные блоки индекса/таблицы.
Но, имхо, это малоактуально, т.к. кэш и так нормально поддерживает свое состояние, если его объем достаточен.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
06.09.2015, 10:27:33
    #39044183
MasterZiv
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
Lumixmiksoft,

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

Если я правильно понял его идею, то он рассказывает об ускорении запросов за счет данных, которые ещё не успел убить сборщик мусора. Именно отсюда появляется понятие фантомной памяти. То есть это как бы русская рулетка. Как повезет.

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

Кэш данных имеет только InnoDB -- это важно знать о MySQL. MyISAM имеет только кэш для индексов.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
06.09.2015, 10:59:06
    #39044196
netwind
netwind
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
MasterZivКэш данных имеет только InnoDB -- это важно знать о MySQL. MyISAM имеет только кэш для индексов.
Ну тогда еще важно знать, что данные MyISAM прекрасно кешируются в кеше ОС.

Да в принципе, все о работе компьютера важно знать нормальному программисту, если он не хипстер нахватавшийся верхов.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
06.09.2015, 13:28:19
    #39044250
MasterZiv
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
netwindMasterZivКэш данных имеет только InnoDB -- это важно знать о MySQL. MyISAM имеет только кэш для индексов.
Ну тогда еще важно знать, что данные MyISAM прекрасно кешируются в кеше ОС.



ага, и ОС конечно же прекрасно знает, где у MySQL какие данные лежат...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
06.09.2015, 21:13:00
    #39044410
Lumix
Lumix
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
MasterZiv, ок, теперь до меня дошло что к чему!

И видимо, чисто исторически этот кеш сначала придумали, чтобы обеспечить механизм транзакций, а уже затем прикрутили для ускорения вычислений. Но это уже мои догадки, и они не имеют отношения к делу...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
06.09.2015, 21:17:09
    #39044412
Lumix
Lumix
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
netwindДа в принципе, все о работе компьютера важно знать нормальному программисту, если он не хипстер нахватавшийся верхов.

я понимаю, что это оффтопик, но пользуясь случаем прошу просветить по поводу терминов. я, к сожалению, плохо владею молодежными понятиями и все это время думал, что хипстер - это именно продвинутый кодер, но с макбуком, с модной прической, часто с бородой, в таких очках с черной пластмассовой оправой и чашкой кофе из старбакса. Я думал, что хипстер - это синоним к слову гик. А вот у вас вроде как хипстер уже используется в смысле близком к тому, что у нас в Екб называют быдлокодер, причем скорее даже ближе к понятию понторылый быдлокодер. Можете пару слов, чисто для просвещения разъяснить кто их них кто?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
06.09.2015, 22:06:46
    #39044433
netwind
netwind
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
Lumixчто хипстер - это именно продвинутый кодер, но с макбуком, с модной прической, часто с бородой, в таких очках с черной пластмассовой оправой и чашкой кофе из старбакса. Я думал, что хипстер - это синоним к слову гик. А вот у вас вроде как хипстер уже используется в смысле близком к тому, что у нас в Екб называют быдлокодер, причем скорее даже ближе к понятию понторылый быдлокодер. Можете пару слов, чисто для просвещения разъяснить кто их них кто?
Вот именно, что чувак с модной прической по определению недавно в ИТ. Он может быть продвинутым, но не имел возможности изучать ассемблер, предсказание кеша процессора, архитектуру и кеш ОС ( в обсуждаемом случае ) просто потому, что это уже не модно. Не может понимать как низкоуровневые механизмы повлияют на то, что он сейчас использует. Писать на ассемблере не нужно. Но помнить про него нужно. Тогда не возникнет вопросов что влияет на скорость повторных запросов в mysql.

Резюме : программист должен быть в свитере. Круглый год!
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
06.09.2015, 22:42:31
    #39044455
MasterZiv
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
LumixMasterZiv, ок, теперь до меня дошло что к чему!

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

Они также неверны. Кэш к транзакциям очень мало отношения имеет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.09.2015, 00:21:17
    #39044506
Lumix
Lumix
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
MasterZiv, ок, понял!
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.09.2015, 08:04:57
    #39044557
Arhat109
Arhat109
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
Lumix,

Выскажу свое ИМХО:

В целом ориентироваться на кеш в части скорости - плохая практика.
1. При 100% однократном выполнении любой кеш замедляет работу. Что кеш ОС, что Мускуля, что любой иной. На одном из моих проектов (не мной начаты, моя оптимизация работы) стояло: кеш ОС (по умолчанию, кудаж без него), query-cahce, кеш Иннодебила достаточно большой с 53% попаданий ... + мемкеш на стороне клиента мускуля + "ручной" кеш выбранных данных в памяти ... при профилировании работы "от начала до конца" одновременно с нагрузочным тестированием ресурса с имитацией деятельности операторов ... внезапно выяснилось что уникальность запросо к сервису и БД в целом составила более 80%. То есть 80% работы ресурса были однократными на протяжении 2-х суток. Устранение кешей и перенастройка БД, с частичным переходом к таблицам in memory ... снизило требования по оперативе с 30Мб до "0.27Мб" ... "на операцию" и повысило итоговую скорость работы около 10 раз.

2. Чтобы эффективно пользоваться кешем надо точно знать какие данные и как часто ПОВТОРНО переиспользуются. Их, как правило, немного ... если точно знать конечно. Размещение (в т.ч. и предварительное) их в память - решает большую часть вопросов. Как правило, кеши работают на "средних" логиках предсказаний и "со временем работы", постепенно конечно заполняются именно ими. Но, в таком случае ресурс обороты набирает "постепенно". Как пример, ещё одна моя работа по оптимизации БД мускуля. При тестировании выяснилось, что на 16 гектар данных требуется около 12 гектар оперативы ... а их было "всего" 8. На всё, в т.ч. и видеопамять :) Но, при нагрузочном тестировании оказалось что для 63% попадания в кеш требуется кешировать всего ... 500метров. Правильное переназначение таблиц и предзагрузка в мемкеш "самого необходимого клиенту" ... и выделенный Иннодебилу кеш в 3 гектара, на протяжении полугода работы без выключений стабильно НЕ заполнялся полностью ... примерно 15% оставалось свободным.

3. Кеши точно также как и любое ПО ... содержат ошибки. Попадал несколько раз (однажды даже тут писал где-то), что по запросу с агрегацией получал "соседние записи" вместо требуемых... кеш однако, как выяснилось ... мускуль был "не причем". :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.09.2015, 08:08:28
    #39044558
Arhat109
Arhat109
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
Arhat109,

Ну и ещё вспомнилось: Первый Доом. Вполне себе держал графику на приемлемой скорости несмотря на явно недостаточную вычислительную мощь тогдашних 486 и видеокарт ... когда списался с автором, то получил движок, который ... весь сидел в кеше проца. При загрузке игры кеш проца загружался движком и закрывался от обновлений. Вот и всё "решение". :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.09.2015, 10:35:07
    #39044669
miksoft
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
Arhat109движок, который ... весь сидел в кеше процаЧто-то не верится. Там весь встроенный кэш был 8 или 16 Кбайт без разделения на кэш инструкций и данных. А внешний кэш был далеко не всегда.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.09.2015, 11:57:52
    #39044760
Arhat109
Arhat109
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
miksoft,

12килобайт. Движок полностью на асме. Тоже тогда офигел как можно решать задачки. Получал "взамен" своего драйвера EGA, тоже на асме, отрисовывавшем 8-12 кадров в сек. в режиме "псевдографики" спрайтами 8х8 точек на 286 12-16Мгц. Таблицы спрайтов (шрифт) - хоть на всю память еги... эх, давно это было... :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.09.2015, 12:31:55
    #39044823
netwind
netwind
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоимость повторных запросов
Хорошим примером тут будет nginx.
То есть, как бы кода на ассемблере почти нет, каких-то малопонятных фокусов нет, однако есть это:
авторПараметр hash bucket size всегда выравнивается до размера, кратного размеру строки кэша процессора. Это позволяет ускорить поиск ключа в хэше на современных процессорах, уменьшив число обращений к памяти.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Стоимость повторных запросов / 25 сообщений из 25, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 372ms
Закрыть
start [/forum/topic.php?fid=47&mobile=1&tid=1832746]:
 0ms
get settings:
 10ms
get forum list:
 21ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 37ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 51ms
get tp. blocked users:
 1ms
others: 233ms
total:  372ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]