Запрос требующийся оптимизировать (время выполнения от 0.7-1 секунды). Можно ли его ещё ускорить?:





Ранее этот же выше представленный запрос был мной оптимизирован, вот так он первоначально выглядел (время выполнения от 2.5 -3 сек):





Explain и SHOW INDEX :

Akina,
посмотрел ваш вариант, работает раза в два в среднем быстрее, но это не совсем тот запрос у вас получился что в первоначальном виде у меня в топике. Мне нужно получить помимо ID игр ещё и все данные по ним из таблицы `game`, а у вас в запросе таблица `game` не участвует. Понятно, что на этом как раз и происходит выйгрыш в производительности, при этом индекс по (date,game_id) я создал.

miksoft,

Создал составной индекс: CREATE INDEX date_game_id ON game_views(`date`, `game_id`);

В принципе скорость выполнения повысилась, но не скажу, что существенно, хотелось бы ещё побыстрее. Запрос стал выполняться с 0.5 - 0.8 сек. Может бы можно ещё как-то улучшить?

[quot okuznetsov]miksoft,

miksoft,

Предполагаю, что вы на 2-ом скриншоте увидили запрос, поэтому подумали, что не менял на count(*). На самом деле это старая строчка с предыдущего скриншота, я не стал её изменять на новую.

Изменение на count(*) не чего существенного не дали, максимум если и улучшилось то не более чем в среднем не более 0.05 сек

miksoft,

со звёздочкой или без неё на план выполнения ни как не повлияло, explain выдаёт абсолютно одинаковые данные

просто интересно: почему советуете через звёздочку? почему так лучше?

max_heap_table_size и tmp_table_size я ранее настраивал когда оптимизировал mysql несколько месяцев назад, нашёл оптимальные настройки, uptime сервера стабилизировал и остановился на этом. И теперь побаиваюсь трогать. Сейчас они установлено 64Мб. На сколько требуется увеличить приблизительно?

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

Akina,

Прошу прощения, невнимательность с моей стороны. Попробовал ещё раз ваш вариант, изменений не произошло. План выполнения запроса не изменился и такой же как на 2 скриншоте.

miksoftokuznetsovпросто интересно: почему советуете через звёздочку? почему так лучше?Во-первых, так выше читаемость - сразу понятно, что нужно количество записей в группе, не надо понимать, а что это за поле такое подсунуто.
Во-вторых, в вашем случае MySQL догадался что это поле NOT NULL и по факту его можно не проверять. Но я не поручусь, что он будет догадываться об этом всегда. Т.е. внезапно он может решить, что нужно прочитать это поле из таблицы, что сломает всю логику использования индекса и резко увеличит время работы запроса.

Спасибо за развёрнутый ответ. Сейчас всё понял.

okuznetsovmax_heap_table_size и tmp_table_size я ранее настраивал когда оптимизировал mysql несколько месяцев назад, нашёл оптимальные настройки, uptime сервера стабилизировал и остановился на этом. И теперь побаиваюсь трогать. Сейчас они установлено 64Мб. На сколько требуется увеличить приблизительно?Сложно сказать, по идее 64 МБ должно быть достаточно. Если общий запас оперативки позволяет, то попробуйте увеличить до 256 МБ в конкретной сессии, где выполняется этот запрос. Если поможет - подбирайте пороговое значение половинным делением и сделайте запас в 20% и на рост данных в будущем. Если не поможет - можно ничего не делать, просто закрыть текущую сессию.

Честно говоря не знаю как увеличить до 256 МБ в конкретной сессии, поэтому увеличил для всех сессий и протестировал в реальных условиях. увеличивал до 384 Мб и затем снижал, в принципе не увидел какого-то существенного результата, поэтому поставил 64Мб

miksoftokuznetsovЧестно говоря не знаю как увеличить до 256 МБ в конкретной сессии


Спасибо, буду теперь знать

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

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

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

Не совсем понял про решение "группировку выделять в предрассчитанную таблицу"?

AkinamiksoftДык стал же, насколько я вижуМда... совсем слепой стал...
Но дальше я лично не вижу путей оптимизации именно запроса - теперь только и остаётся что настройками рулить. Что мне в данном случае представляется сомнительным - из индекса выгребается в сорт-буфер миллион записей, это метров 16-20, да 70к записей во второй таблице со сканом по первичному индексу - чего там ещё растить-то, на какие потребности?

Честно говоря не я первоначальный разработчик данных запросов и таблиц, до меня их было даже несколько. Поэтому сейчас я тоже разбираюсь логике работы и вообще всего происходящего. После вашего ответа, начал разбираться и сегодня, обнаружил, что при добавлении новых игр - в таблицу game добавляется одна запись, а в таблицу game_views около 10 000, и так происходит вроде бы ежедневно уже более года. Зачем и для чего это сделано - для меня пока загадка, но понимаю, что так не должно быть и соответственно сейчас начал решать эту первоочередную проблему. Планирую разобраться и устранить запись такой пачки данных в таблицу game_views, а затем почистить саму таблицу. соответственно данных в таблице станет меньше как минимум в несколько сотен раз и запрос будет выполняться быстрее.