powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Требуется помощь в оптимизации запроса
51 сообщений из 51, показаны все 3 страниц
Требуется помощь в оптимизации запроса
    #38997856
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Запрос требующийся оптимизировать (время выполнения от 0.7-1 секунды). Можно ли его ещё ускорить?:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SELECT *
FROM `game` `t` 
JOIN
(
SELECT game_views.game_id, count(game_views.id) AS gv_cnt
FROM `game_views` `game_views` 
WHERE (`game_views`.`date` >  DATE(NOW() - INTERVAL 1 MONTH))
GROUP BY game_views.game_id
ORDER BY gv_cnt DESC
LIMIT 28 OFFSET 224
) as t1 ON (`t`.`id`=`t1`.`game_id`)




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

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
SELECT
t.id AS t0_c0,
t.catid AS t0_c1,
t.title AS t0_c2,
t.object AS t0_c3,
t.description AS t0_c4,
t.image AS t0_c5,
t.votes_summ AS t0_c6,
t.votes_count AS t0_c7,
t.views AS t0_c8,
t.favorites AS t0_c9,
t.date AS t0_c10,
t.is_uniq AS t0_c11,
count(game_views.id) AS gv_cnt,
category.id AS t1_c0,
category.slug AS t1_c1,
category.title AS t1_c2,
category.description AS t1_c3,
category.meta_title AS t1_c4,
category.parent AS t1_c5,
category.total_views AS t1_c6,
game_views.id AS t4_c0,
game_views.game_id AS t4_c1,
game_views.date AS t4_c2,
game_views.user_id AS t4_c3
FROM `game` `t`  
LEFT OUTER JOIN `category` `category` ON (`t`.`catid`=`category`.`id`)  
INNER JOIN `game_views` `game_views` ON (`game_views`.`game_id`=`t`.`id`)
WHERE (`game_views`.`date` > DATE(NOW() - INTERVAL 7 DAY))
GROUP BY game_views.game_id
ORDER BY gv_cnt DESC
LIMIT 28




Explain и SHOW INDEX :
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38997903
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1) count(game_views.id) заменить на count(*)
2) сделать индекс (`date`,game_id) на таблице game_views. После создания индекса сделать ANALYZE TABLE всем задействованным таблицам.


okuznetsovРанее этот же выше представленный запрос был мной оптимизирован, вот так он первоначально выгляделЗапросы совсем не эквивалентные, так что сравнивать их бессмысленно.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38997913
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Перепишите подзапрос как

Код: sql
1.
2.
3.
4.
5.
6.
SELECT game_views.game_id, count(game_views.game_id) AS gv_cnt
FROM `game_views` `game_views` 
WHERE (`game_views`.`date` >  DATE(NOW() - INTERVAL 1 MONTH))
GROUP BY game_views.game_id
ORDER BY 2 DESC
LIMIT 28 OFFSET 224


и создайте индекс по (date,game_id).
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998011
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Akina,
посмотрел ваш вариант, работает раза в два в среднем быстрее, но это не совсем тот запрос у вас получился что в первоначальном виде у меня в топике. Мне нужно получить помимо ID игр ещё и все данные по ним из таблицы `game`, а у вас в запросе таблица `game` не участвует. Понятно, что на этом как раз и происходит выйгрыш в производительности, при этом индекс по (date,game_id) я создал.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998015
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoft,

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

В принципе скорость выполнения повысилась, но не скажу, что существенно, хотелось бы ещё побыстрее. Запрос стал выполняться с 0.5 - 0.8 сек. Может бы можно ещё как-то улучшить?
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998017
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
[quot okuznetsov]miksoft,
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998020
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsov,

Первый пункт забыли сделать.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998032
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoft,

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

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

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SELECT *
FROM `game` `t` 
JOIN
(
SELECT game_views.game_id, count(*) AS gv_cnt
FROM `game_views` `game_views` 
WHERE (`game_views`.`date` >  DATE(NOW() - INTERVAL 1 MONTH))
GROUP BY game_views.game_id
ORDER BY gv_cnt DESC
LIMIT 28
) as t1 ON (`t`.`id`=`t1`.`game_id`);
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998046
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsovИзменение на count(*) не чего существенного не дали, максимум если и улучшилось то не более чем в среднем не более 0.05 секТем не менее, лучше писать через звездочку, если не нужно принципиально иначе.

На план это повлияло?

Еще можно попробовать увеличить max_heap_table_size и tmp_table_size, чтобы временный файл не падал на диск, а оставался в оперативке.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998070
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoft,

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

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

max_heap_table_size и tmp_table_size я ранее настраивал когда оптимизировал mysql несколько месяцев назад, нашёл оптимальные настройки, uptime сервера стабилизировал и остановился на этом. И теперь побаиваюсь трогать. Сейчас они установлено 64Мб. На сколько требуется увеличить приблизительно?
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998078
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
забыл уточнить - может быть удалить оставшиеся два индекса: date и game_id, которые были созданы мной ранее до составного (date, game_id)? или пусть будут все три?
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998091
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsovпросто интересно: почему советуете через звёздочку? почему так лучше?Во-первых, так выше читаемость - сразу понятно, что нужно количество записей в группе, не надо понимать, а что это за поле такое подсунуто.
Во-вторых, в вашем случае MySQL догадался что это поле NOT NULL и по факту его можно не проверять. Но я не поручусь, что он будет догадываться об этом всегда. Т.е. внезапно он может решить, что нужно прочитать это поле из таблицы, что сломает всю логику использования индекса и резко увеличит время работы запроса.


okuznetsovmax_heap_table_size и tmp_table_size я ранее настраивал когда оптимизировал mysql несколько месяцев назад, нашёл оптимальные настройки, uptime сервера стабилизировал и остановился на этом. И теперь побаиваюсь трогать. Сейчас они установлено 64Мб. На сколько требуется увеличить приблизительно?Сложно сказать, по идее 64 МБ должно быть достаточно. Если общий запас оперативки позволяет, то попробуйте увеличить до 256 МБ в конкретной сессии, где выполняется этот запрос. Если поможет - подбирайте пороговое значение половинным делением и сделайте запас в 20% и на рост данных в будущем. Если не поможет - можно ничего не делать, просто закрыть текущую сессию.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998094
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsovзабыл уточнить - может быть удалить оставшиеся два индекса: date и game_id, которые были созданы мной ранее до составного (date, game_id)? или пусть будут все три?Если они не используются в других запросах, то имеет смысл удалить, т.к. они замедляют операции модификации данных.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998096
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsovэто не совсем тот запрос у вас получился что в первоначальном виде у меня в топикеЯ вообще-то русским по белому пишу, что это ТОЛЬКО ПОДЗАПРОС.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998110
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Akina,

Прошу прощения, невнимательность с моей стороны. Попробовал ещё раз ваш вариант, изменений не произошло. План выполнения запроса не изменился и такой же как на 2 скриншоте.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998138
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsovПлан выполнения запроса не изменился и такой же как на 2 скриншоте.Вы хотите сказать, что сервер не стал использовать покрывающий индекс и продолжил использовать индекс по полю date? Что-то неладно в королевстве Датском...
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998140
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoftokuznetsovпросто интересно: почему советуете через звёздочку? почему так лучше?Во-первых, так выше читаемость - сразу понятно, что нужно количество записей в группе, не надо понимать, а что это за поле такое подсунуто.
Во-вторых, в вашем случае MySQL догадался что это поле NOT NULL и по факту его можно не проверять. Но я не поручусь, что он будет догадываться об этом всегда. Т.е. внезапно он может решить, что нужно прочитать это поле из таблицы, что сломает всю логику использования индекса и резко увеличит время работы запроса.

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

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

Честно говоря не знаю как увеличить до 256 МБ в конкретной сессии, поэтому увеличил для всех сессий и протестировал в реальных условиях. увеличивал до 384 Мб и затем снижал, в принципе не увидел какого-то существенного результата, поэтому поставил 64Мб
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998144
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AkinaokuznetsovПлан выполнения запроса не изменился и такой же как на 2 скриншоте.Вы хотите сказать, что сервер не стал использовать покрывающий индекс и продолжил использовать индекс по полю date? Что-то неладно в королевстве Датском...Дык стал же, насколько я вижу
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998153
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsovЧестно говоря не знаю как увеличить до 256 МБ в конкретной сессии
Код: sql
1.
SET SESSION max_heap_table_size=256000000
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998158
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftДык стал же, насколько я вижуМда... совсем слепой стал...
Но дальше я лично не вижу путей оптимизации именно запроса - теперь только и остаётся что настройками рулить. Что мне в данном случае представляется сомнительным - из индекса выгребается в сорт-буфер миллион записей, это метров 16-20, да 70к записей во второй таблице со сканом по первичному индексу - чего там ещё растить-то, на какие потребности?
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998173
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть еще путь - группировку выделять в предрассчитанную таблицу. Может пострадать оперативность и точность, но насколько это важно - зависит от задачи.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998724
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoftokuznetsovЧестно говоря не знаю как увеличить до 256 МБ в конкретной сессии
Код: sql
1.
SET SESSION max_heap_table_size=256000000



Спасибо, буду теперь знать
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998738
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoftЕсть еще путь - группировку выделять в предрассчитанную таблицу. Может пострадать оперативность и точность, но насколько это важно - зависит от задачи.

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

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

Не совсем понял про решение "группировку выделять в предрассчитанную таблицу"?
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998748
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
AkinamiksoftДык стал же, насколько я вижуМда... совсем слепой стал...
Но дальше я лично не вижу путей оптимизации именно запроса - теперь только и остаётся что настройками рулить. Что мне в данном случае представляется сомнительным - из индекса выгребается в сорт-буфер миллион записей, это метров 16-20, да 70к записей во второй таблице со сканом по первичному индексу - чего там ещё растить-то, на какие потребности?

Честно говоря не я первоначальный разработчик данных запросов и таблиц, до меня их было даже несколько. Поэтому сейчас я тоже разбираюсь логике работы и вообще всего происходящего. После вашего ответа, начал разбираться и сегодня, обнаружил, что при добавлении новых игр - в таблицу game добавляется одна запись, а в таблицу game_views около 10 000, и так происходит вроде бы ежедневно уже более года. Зачем и для чего это сделано - для меня пока загадка, но понимаю, что так не должно быть и соответственно сейчас начал решать эту первоочередную проблему. Планирую разобраться и устранить запись такой пачки данных в таблицу game_views, а затем почистить саму таблицу. соответственно данных в таблице станет меньше как минимум в несколько сотен раз и запрос будет выполняться быстрее.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998769
login_sqlru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
AkinamiksoftДык стал же, насколько я вижуМда... совсем слепой стал...
Но дальше я лично не вижу путей оптимизации именно запроса - теперь только и остаётся что настройками рулить. Что мне в данном случае представляется сомнительным - из индекса выгребается в сорт-буфер миллион записей, это метров 16-20, да 70к записей во второй таблице со сканом по первичному индексу - чего там ещё растить-то, на какие потребности?

А че гадать то с max_heap_table_size и tmp_table_size, посмотри размер файлов в /tmp файлы типа #sql_****.MYD.


еще, индекс вы создали и mysql его использует, но key_len то 3 байта. значить сработал только часть.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998770
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
login_sqlruиндекс вы создали и mysql его использует, но key_len то 3 байта. значить сработал только часть.Это не так. Часть - используется при операциях связывания/отбора/сортировки... но индекс-то покрывающий, и на самом деле используется весь - просто сведения об использовании покрывающего индекса для экстракции данных нигде и никак не отображаются.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #38998935
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsovНе совсем понял про решение "группировку выделять в предрассчитанную таблицу"?Это значит хранить еще одну таблицу с примерно тем же содержимым, которое получается у в результате подзапроса.
Например, из полей (дата, game_id, cnt). Т.е. тот же счетчик, но с разбивкой по дням и играм. ПК - два первых поля.
А запрос превратится примерно в такой:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SELECT *
FROM `game` `t` 
JOIN
(
SELECT game_stat.game_id, SUM(cnt) gv_cnt
FROM game_stat
WHERE game_stat.`date` >  DATE(NOW() - INTERVAL 1 MONTH)
GROUP BY game_stat.game_id
ORDER BY game_stat.gv_cnt DESC
LIMIT 28 OFFSET 224
) as t1 ON `t`.`id`=`t1`.`game_id`



Поддерживать эту таблицу можно двумя способами:
1) INSERT ... ON DUPLICATE KEY UPDATE при каждом событии, которое нужно подсчитывать (т.е. фактически при записи в таблицу game_views). Оперативность практически мгновенная, но замедляется запись событий.
2) Периодически выполнять группирующий подзапрос по сегодняшнему дню и его результатом апдейтить сегодняшние записи в таблице game_stat. Так нет дополнительной задержки при записи событий, но страдает оперативность - появляется задержка от момента события до момента, когда его результат увидят пользователи.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003200
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoft,

Спасибо вам, воспользовался второй реализацией с некоторыми дополнениями.

Сделал так:
1) создал новую таблицу game_views_popular_month содержащую два поля (game_id, gv_cnt)
2) написал хранимую процедуру со следующим содержимым для поддержания таблицы game_views_popular_month.

CALL number_games_page (28)

Содержимое хранимой процедуры (понятно, что содержимое не идеально, доведу до идеала позже, главное понятен смысл):

DELETE FROM game_views_popular_month;
INSERT INTO game_views_popular_month (game_id, gv_cnt)
SELECT game_views.game_id, count(*) AS gv_cnt
FROM `game_views` `game_views`
WHERE (`game_views`.`date` = DATE(NOW() - INTERVAL 1 MONTH))
GROUP BY game_views.game_id
ORDER BY gv_cnt DESC
LIMIT number;

Вызов на выполнение хранимой процедуры осуществляется по крону один раз ночью (когда нагрузка на сервер минимальна), происходит обновление таблицы game_views_popular_month новыми данными (записываются 28 новых записей - это популярные игры за месяц на текущую дату) из таблицы game_views. Таким образом удалось исключить из запроса большую проблемную таблицу содержащую более 1 000 000 записей и ежедневно наполняемую в районе 10 000 новых записей. В результате всего удалось ещё в 3 раза ускорить выполнение проблемного запроса.

Спасибо за помощь!
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003216
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Забыл показать запрос, который получился в результате нашей оптимизации:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT * 
FROM `game` `t` 
JOIN
(
SELECT * 
FROM game_views_popular_month 
ORDER BY game_views_popular_month.gv_cnt DESC
) 
as `t1` ON `t`.`id`=`t1`.`game_id`




Теперь запрос выполняется в районе 0.150-0.250 сек
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003221
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsov,

а если напрямую сджойнить, без промежуточной материализации - не быстрее будет?
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003246
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
tanglirokuznetsov,

а если напрямую сджойнить, без промежуточной материализации - не быстрее будет?

Я вас не понимаю? По подробней напишите? Разве первоначальный запрос который требовалось оптимизировать не напрямую был сджойнин без материализации?
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003254
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsov,

в первоначальном запросе было задействовано больше таблиц и присутствовал лимит.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003272
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsov
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT * 
FROM `game` `t` 
JOIN
(
SELECT * 
FROM game_views_popular_month 
ORDER BY game_views_popular_month.gv_cnt DESC
) 
as `t1` ON `t`.`id`=`t1`.`game_id`


1) ORDER BY в подзапросе не имеет смысла - он всё равно будет проигнорирован. А если его убрать - то подзапрос теряет смысл.
2) Замена звёздочек на список реально необходимых полей способен ускорить запрос, особенно при наличии индексов, совсем особенно - если они покрывающие.

Finally:
Код: sql
1.
2.
3.
4.
SELECT t.fields, t1.fields
FROM game t, game_views_popular_month  t1
WHERE t.id = t1.game_id
-- ORDER BY t1.gv_cnt DESC
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003453
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Akina,

автор1) ORDER BY в подзапросе не имеет смысла - он всё равно будет проигнорирован. А если его убрать - то подзапрос теряет смысл.


Использование ORDER BY придаёт запросу реальную отсортированную упорядоченную выдачу, при этом он НЕ ИГНОРИРУЕТСЯ, а реально работает, ваши утверждения НЕ ВЕРНЫ!

автор2) Замена звёздочек на список реально необходимых полей способен ускорить запрос, особенно при наличии индексов, совсем особенно - если они покрывающие.

Я в курсе про звёздочки+поля+индексы (я думаю уже вообще мало людей осталось который не в курсе), но реального ускорения выполнения запроса от использования полей в место звёздочек в данном случае я не увидел, как выполнялся за своё время так и выполняется в этих временных интервалах, при этом уменьшилось число символов в запросе и повысилась читабельность
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003470
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
tanglirokuznetsov,

в первоначальном запросе было задействовано больше таблиц и присутствовал лимит.

Во-первых: таблиц задействовано столько же (одну таблицу с более чем 1 000 000 записей заменили на другую в которой всегда 28 записей, которая подзапросом набивается один раз ночью по крону. На этом в скорости и выйграли!)

Во-вторых: если что-то хотите посоветовать/подсказать, то делайте это, не нужно отвлекать понапрасну, ФЛУДИТЬ и посты себе набивать какой-то х.... Я тоже умею ПЕРЕСКАЗЫВАТЬ очевидные вещи - это я про "присутствие лимита"
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003471
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsovИспользование ORDER BY придаёт запросу реальную отсортированную упорядоченную выдачу, при этом он НЕ ИГНОРИРУЕТСЯ, а реально работает, ваши утверждения НЕ ВЕРНЫ!Есть определённая категория граждан, которым везёт... но даже им везёт не всегда. Так что когда (не "если", а именно "когда") разобьёшь на этом своём ложном убеждении физиономию - не плачься.

okuznetsovЯ в курсе про звёздочки+поля+индексы (я думаю уже вообще мало людей осталось который не в курсе), но реального ускорения выполнения запроса от использования полей в место звёздочек в данном случае я не увиделЗримого ускорения ты не видишь скорее всего потому, что не выполнены все указанные мной условия. Или потому что таблицы у тебя с кукиш размером. Или потому, что ты выполняешь запрос в модельно-эксклюзивных, а не боевых, условиях, когда каждый килобайт оперативки и тик процессора на вес золота.

Для повышения читабельности запроса используют его форматирование. А экономия байтов... тебе что, приплачивают за неё, что ли?
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003491
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
okuznetsov,

Это правильный запрос (в принципе можно и без ORDER BY обойтись, но тогда выводимые игры на странице будут не отсортированы по популярности, если кому нужна такая выдача, то пожалуйста я не против. В данном случае по проведённым мной тестам без ORDER BY - ни как не повлияло на скорость выполнения запроса)

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT * 
FROM `game` `t` 
JOIN
(
SELECT * 
FROM game_views_popular_month 
ORDER BY game_views_popular_month.gv_cnt DESC
) 
as `t1` ON `t`.`id`=`t1`.`game_id`
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003599
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Akina,

Не забывайте как моя тема называется: "требуется помощь в оптимизации запроса", подразумевается, что не кому-то, а именно мне нужно помочь, и именно в моих условиях и на моих объёмах данных - запрос ускорить.

okuznetsovИспользование ORDER BY придаёт запросу реальную отсортированную упорядоченную выдачу, при этом он НЕ ИГНОРИРУЕТСЯ, а реально работает, ваши утверждения НЕ ВЕРНЫ!Есть определённая категория граждан, которым везёт... но даже им везёт не всегда. Так что когда (не "если", а именно "когда") разобьёшь на этом своём ложном убеждении физиономию - не плачься.[/quot]

Уже ни один раз видел (не помню на каких форумах) похожее высказывание, разумеется не мне адресованное, читал у других. Теперь вот и мне посоветовали. Постараюсь не плакать)

Давайте не будем ругаться, в данном случае вы не правы, я вам об этом сказал. Везения здесь нет - на ORDER BY повторюсь в данном случае ОСНОВАНА ЛОГИКА ЗАПРОСА, кстати и вы об этом выше сказали.

авторчто не выполнены все указанные мной условия
Читайте выше, все ваши предложения/условия я соблюдал и пробовал в реальных условиях

Код: sql
1.
Или потому что таблицы у тебя с кукиш размером


Размеры таблиц я указал на скриншоте, таблица выросла до таких размеров за 2 года, по расчётам ещё за 5 лет может вырасти на 500% максимум, и я уверен, что это тоже для вас будет кукиш размер. До объёмов таблиц о которых вы говорите и я предполагаю врятли дело дойдёт.

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

Для повышения читабельности запроса используют его форматирование. А экономия байтов... тебе что, приплачивают за неё, что ли?[/quot]
Вы утрируете, нашли к чему цепляться. Понятно же что имеется ввиду.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003621
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsovв данном случае вы не правы, я вам об этом сказал. Везения здесь нет
«Муж, упорный в своих намерениях» (© Гораций).
Да пожалуйста, оставайтесь и дальше при своём убеждении.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003672
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsov,

Akina все-таки скорее прав насчет сортировки в подзапросе. ORDER BY может быть проигнорирован, если нет LIMIT-а. И я устойчиво помню, что видел этот момент в доке. Однако повторно найти пока не получается. Но нашел другое подтверждение - https://blog.hqcodeshop.fi/archives/25-MySQL-5.6-subquery-ORDER-BY-behaviour-changed-from-5.5.html
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003675
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftИ я устойчиво помню, что видел этот момент в доке. Однако повторно найти пока не получается.Пока удалось найти только применительно к UNION:
http://dev.mysql.com/doc/refman/5.5/en/union.html If ORDER BY appears without LIMIT in a SELECT, it is optimized away because it will have no effect anyway.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003683
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А, кстати, если ORDER BY в подзапросе и выполнялся бы реально, JOIN все равно не обязан сохранить эту сортировку. Зависит от метода его выполнения (а начиная с версии 5.6 их стало более одного) и порядка соединения, выбранного оптимизатором.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39003729
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Угу. Особенно если оптимизатор решит, что спервоначалу надо сканить таблицу game, и только потом кэшированный подзапрос. А при левом связывании это вообще практически гарантировано.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39004078
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsovВо-первых: таблиц задействовано столько же (одну таблицу с более чем 1 000 000 записей заменили на другую в которой всегда 28 записей, которая подзапросом набивается один раз ночью по крону. На этом в скорости и выйграли!)Ну тогда см. выше пост Акины.
okuznetsovВо-вторых: если что-то хотите посоветовать/подсказать, то делайте это, не нужно отвлекать понапрасну, ФЛУДИТЬ и посты себе набивать какой-то х.... Я тоже умею ПЕРЕСКАЗЫВАТЬ очевидные вещи - это я про "присутствие лимита"Тынц на пост с моим флудом OR GTFO. Пока что "х...." (насчёт ордербай) несёте именно вы.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39004341
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
tanglir,

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

Код: sql
1.
а если напрямую сджойнить, без промежуточной материализации - не быстрее будет?



Код: sql
1.
в первоначальном запросе было задействовано больше таблиц и присутствовал лимит. 



Может быть я туплю уже, но я реально не понимаю из ваших фраз, что вы предлагаете?
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39004342
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoft,

Я понял вас, спасибо за исчерпывающий всё расставляющий на свои места ответ, сейчас полностью согласен со всем. На данный момент на сервере mysql 5.5.31, но в будущем не исключён вариант на 5.6. Хорошо, что сейчас всплыли данные факты, честно говоря не готов был к такому, спасибо за полезную и интересную информацию.

Akina,

В следующий раз буду более внимателен к вашим ответам/советам, понял, что нужно вам задавать доп. вопросы (т.к. по некоторым моментам сложно понять вашу мысль). Если бы вы аргументировали свою позицию в похожем на miksoft виде, то с моей стороны не возникло ни каких сомнений. Надеюсь, что вы не в обиде на меня. Также хотелось бы сказать - в спорах рождается истина (не помню автора). Хорошая получилась тема на форуме, надеюсь в будущем кому-то окажется полезной.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39004344
okuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Без order by в данном случае мне необходим, предполагаю, что правильнее LIMIT добавить и RIGHT JOIN? Или всё-таки использовать STRAIGHT_JOIN?

SELECT *
FROM `game` `t`
##STRAIGHT_JOIN
RIGHT JOIN
(
SELECT *
FROM game_views_popular_month
ORDER BY game_views_popular_month.gv_cnt DESC
LIMIT 28
)
as `t1` ON `t`.`id`=`t1`.`game_id`
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39004356
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если используется стороннее связывание, STRAIGHT_JOIN избыточен. Но и вреда от него не будет никакого.
А насчёт "правильнее" - правильность запроса определяется требуемой логикой получения результата, и варьироваться могут только полностью синтаксически эквивалентные запросы. Ваш же последний запрос неэквивалентен ранее опубликованным...
Думаю, есть смысл ещё раз, но уже с учётом вышесказанного, чётко, грамотно и однозначно сформулировать задачу. Сейчас её понимание слишком размыто.

okuznetsovНадеюсь, что вы не в обиде на меня.Ессессно. У меня есть куча гораздо более увлекательных дел :)
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39004361
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsovБез order by в данном случае мне необходим, предполагаю, что правильнее LIMIT добавить и RIGHT JOIN? Или всё-таки использовать STRAIGHT_JOIN?Возьмите да попробуйте. Мне кажется, что разница будет на уровне погрешности измерения.

И, если я правильно понял, что в LIMIT-е нет необходимости, т.к. в таблице game_views_popular_month нет лишних записей, то зачем тут вообще подзапрос? Почему бы не раскрыть его? Тогда и ORDER BY гарантированно сработал бы, и оптимизатору попроще было бы, да и читать потом такой запрос легче.
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39004379
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okuznetsovМожет быть я туплю уже, но я реально не понимаю из ваших фраз, что вы предлагаете?Акина уже за меня написал: 17871380 .
И что значит "загадочно"? Вы спросили, мол, разве первый запрос не был напрямую сджойнен - я и ответил, что в хоть он и был, но в нём были задействованы не только таблицы, используемые в обсуждаемом варианте (уж извините, не понял, что данные по сути остались те же, только в другой форме).
...
Рейтинг: 0 / 0
Требуется помощь в оптимизации запроса
    #39004392
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, вот (можно сказать, эталонный) пример , показывающий, к чему может привести использование недокументированных фич. Тоже сортировка, кстати.
...
Рейтинг: 0 / 0
51 сообщений из 51, показаны все 3 страниц
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Требуется помощь в оптимизации запроса
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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