|
|
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
Запрос требующийся оптимизировать (время выполнения от 0.7-1 секунды). Можно ли его ещё ускорить?: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Ранее этот же выше представленный запрос был мной оптимизирован, вот так он первоначально выглядел (время выполнения от 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. Explain и SHOW INDEX : ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 13:34:03 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
1) count(game_views.id) заменить на count(*) 2) сделать индекс (`date`,game_id) на таблице game_views. После создания индекса сделать ANALYZE TABLE всем задействованным таблицам. okuznetsovРанее этот же выше представленный запрос был мной оптимизирован, вот так он первоначально выгляделЗапросы совсем не эквивалентные, так что сравнивать их бессмысленно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 14:02:59 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
Перепишите подзапрос как Код: sql 1. 2. 3. 4. 5. 6. и создайте индекс по (date,game_id). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 14:09:00 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
Akina, посмотрел ваш вариант, работает раза в два в среднем быстрее, но это не совсем тот запрос у вас получился что в первоначальном виде у меня в топике. Мне нужно получить помимо ID игр ещё и все данные по ним из таблицы `game`, а у вас в запросе таблица `game` не участвует. Понятно, что на этом как раз и происходит выйгрыш в производительности, при этом индекс по (date,game_id) я создал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 15:07:29 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
miksoft, Создал составной индекс: CREATE INDEX date_game_id ON game_views(`date`, `game_id`); В принципе скорость выполнения повысилась, но не скажу, что существенно, хотелось бы ещё побыстрее. Запрос стал выполняться с 0.5 - 0.8 сек. Может бы можно ещё как-то улучшить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 15:12:59 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
[quot okuznetsov]miksoft, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 15:14:53 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsov, Первый пункт забыли сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 15:17:32 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
miksoft, Предполагаю, что вы на 2-ом скриншоте увидили запрос, поэтому подумали, что не менял на count(*). На самом деле это старая строчка с предыдущего скриншота, я не стал её изменять на новую. Изменение на count(*) не чего существенного не дали, максимум если и улучшилось то не более чем в среднем не более 0.05 сек Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 15:33:24 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsovИзменение на count(*) не чего существенного не дали, максимум если и улучшилось то не более чем в среднем не более 0.05 секТем не менее, лучше писать через звездочку, если не нужно принципиально иначе. На план это повлияло? Еще можно попробовать увеличить max_heap_table_size и tmp_table_size, чтобы временный файл не падал на диск, а оставался в оперативке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 15:50:24 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
miksoft, со звёздочкой или без неё на план выполнения ни как не повлияло, explain выдаёт абсолютно одинаковые данные просто интересно: почему советуете через звёздочку? почему так лучше? max_heap_table_size и tmp_table_size я ранее настраивал когда оптимизировал mysql несколько месяцев назад, нашёл оптимальные настройки, uptime сервера стабилизировал и остановился на этом. И теперь побаиваюсь трогать. Сейчас они установлено 64Мб. На сколько требуется увеличить приблизительно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 16:15:32 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
забыл уточнить - может быть удалить оставшиеся два индекса: date и game_id, которые были созданы мной ранее до составного (date, game_id)? или пусть будут все три? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 16:21:53 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsovпросто интересно: почему советуете через звёздочку? почему так лучше?Во-первых, так выше читаемость - сразу понятно, что нужно количество записей в группе, не надо понимать, а что это за поле такое подсунуто. Во-вторых, в вашем случае MySQL догадался что это поле NOT NULL и по факту его можно не проверять. Но я не поручусь, что он будет догадываться об этом всегда. Т.е. внезапно он может решить, что нужно прочитать это поле из таблицы, что сломает всю логику использования индекса и резко увеличит время работы запроса. okuznetsovmax_heap_table_size и tmp_table_size я ранее настраивал когда оптимизировал mysql несколько месяцев назад, нашёл оптимальные настройки, uptime сервера стабилизировал и остановился на этом. И теперь побаиваюсь трогать. Сейчас они установлено 64Мб. На сколько требуется увеличить приблизительно?Сложно сказать, по идее 64 МБ должно быть достаточно. Если общий запас оперативки позволяет, то попробуйте увеличить до 256 МБ в конкретной сессии, где выполняется этот запрос. Если поможет - подбирайте пороговое значение половинным делением и сделайте запас в 20% и на рост данных в будущем. Если не поможет - можно ничего не делать, просто закрыть текущую сессию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 16:31:31 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsovзабыл уточнить - может быть удалить оставшиеся два индекса: date и game_id, которые были созданы мной ранее до составного (date, game_id)? или пусть будут все три?Если они не используются в других запросах, то имеет смысл удалить, т.к. они замедляют операции модификации данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 16:32:26 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsovэто не совсем тот запрос у вас получился что в первоначальном виде у меня в топикеЯ вообще-то русским по белому пишу, что это ТОЛЬКО ПОДЗАПРОС. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 16:33:33 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
Akina, Прошу прощения, невнимательность с моей стороны. Попробовал ещё раз ваш вариант, изменений не произошло. План выполнения запроса не изменился и такой же как на 2 скриншоте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 16:42:09 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsovПлан выполнения запроса не изменился и такой же как на 2 скриншоте.Вы хотите сказать, что сервер не стал использовать покрывающий индекс и продолжил использовать индекс по полю date? Что-то неладно в королевстве Датском... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 17:07:17 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
miksoftokuznetsovпросто интересно: почему советуете через звёздочку? почему так лучше?Во-первых, так выше читаемость - сразу понятно, что нужно количество записей в группе, не надо понимать, а что это за поле такое подсунуто. Во-вторых, в вашем случае MySQL догадался что это поле NOT NULL и по факту его можно не проверять. Но я не поручусь, что он будет догадываться об этом всегда. Т.е. внезапно он может решить, что нужно прочитать это поле из таблицы, что сломает всю логику использования индекса и резко увеличит время работы запроса. Спасибо за развёрнутый ответ. Сейчас всё понял. okuznetsovmax_heap_table_size и tmp_table_size я ранее настраивал когда оптимизировал mysql несколько месяцев назад, нашёл оптимальные настройки, uptime сервера стабилизировал и остановился на этом. И теперь побаиваюсь трогать. Сейчас они установлено 64Мб. На сколько требуется увеличить приблизительно?Сложно сказать, по идее 64 МБ должно быть достаточно. Если общий запас оперативки позволяет, то попробуйте увеличить до 256 МБ в конкретной сессии, где выполняется этот запрос. Если поможет - подбирайте пороговое значение половинным делением и сделайте запас в 20% и на рост данных в будущем. Если не поможет - можно ничего не делать, просто закрыть текущую сессию. Честно говоря не знаю как увеличить до 256 МБ в конкретной сессии, поэтому увеличил для всех сессий и протестировал в реальных условиях. увеличивал до 384 Мб и затем снижал, в принципе не увидел какого-то существенного результата, поэтому поставил 64Мб ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 17:08:45 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
AkinaokuznetsovПлан выполнения запроса не изменился и такой же как на 2 скриншоте.Вы хотите сказать, что сервер не стал использовать покрывающий индекс и продолжил использовать индекс по полю date? Что-то неладно в королевстве Датском...Дык стал же, насколько я вижу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 17:10:10 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsovЧестно говоря не знаю как увеличить до 256 МБ в конкретной сессии Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 17:13:38 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
miksoftДык стал же, насколько я вижуМда... совсем слепой стал... Но дальше я лично не вижу путей оптимизации именно запроса - теперь только и остаётся что настройками рулить. Что мне в данном случае представляется сомнительным - из индекса выгребается в сорт-буфер миллион записей, это метров 16-20, да 70к записей во второй таблице со сканом по первичному индексу - чего там ещё растить-то, на какие потребности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 17:20:01 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
Есть еще путь - группировку выделять в предрассчитанную таблицу. Может пострадать оперативность и точность, но насколько это важно - зависит от задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2015, 17:29:55 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
miksoftokuznetsovЧестно говоря не знаю как увеличить до 256 МБ в конкретной сессии Код: sql 1. Спасибо, буду теперь знать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2015, 11:02:30 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
miksoftЕсть еще путь - группировку выделять в предрассчитанную таблицу. Может пострадать оперативность и точность, но насколько это важно - зависит от задачи. Реализация задачи выглядит следующим образом: посетители кликают по радиобоксу, в результате отрабатывается данный запрос, после чего на странице отображается 28 самых играемых (популярных) игр за месяц. В данном случае важна оперативность, а точностью можно пренебречь. Важно чтобы посетители при клике быстро получали результат, пусть будет немного не достоверным. При этом при сегодняшней нагрузке на сайте в 1 секунду одновременно могут выполняться от 2 до 4 запросов, при этом есть ещё несколько других не оптимизированных запросов которые тоже участвуют в формировании отображаемой страницы, поэтому нужно чтобы данный запрос максимально быстро выполнялся. Не совсем понял про решение "группировку выделять в предрассчитанную таблицу"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2015, 11:21:46 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
AkinamiksoftДык стал же, насколько я вижуМда... совсем слепой стал... Но дальше я лично не вижу путей оптимизации именно запроса - теперь только и остаётся что настройками рулить. Что мне в данном случае представляется сомнительным - из индекса выгребается в сорт-буфер миллион записей, это метров 16-20, да 70к записей во второй таблице со сканом по первичному индексу - чего там ещё растить-то, на какие потребности? Честно говоря не я первоначальный разработчик данных запросов и таблиц, до меня их было даже несколько. Поэтому сейчас я тоже разбираюсь логике работы и вообще всего происходящего. После вашего ответа, начал разбираться и сегодня, обнаружил, что при добавлении новых игр - в таблицу game добавляется одна запись, а в таблицу game_views около 10 000, и так происходит вроде бы ежедневно уже более года. Зачем и для чего это сделано - для меня пока загадка, но понимаю, что так не должно быть и соответственно сейчас начал решать эту первоочередную проблему. Планирую разобраться и устранить запись такой пачки данных в таблицу game_views, а затем почистить саму таблицу. соответственно данных в таблице станет меньше как минимум в несколько сотен раз и запрос будет выполняться быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2015, 11:39:03 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
AkinamiksoftДык стал же, насколько я вижуМда... совсем слепой стал... Но дальше я лично не вижу путей оптимизации именно запроса - теперь только и остаётся что настройками рулить. Что мне в данном случае представляется сомнительным - из индекса выгребается в сорт-буфер миллион записей, это метров 16-20, да 70к записей во второй таблице со сканом по первичному индексу - чего там ещё растить-то, на какие потребности? А че гадать то с max_heap_table_size и tmp_table_size, посмотри размер файлов в /tmp файлы типа #sql_****.MYD. еще, индекс вы создали и mysql его использует, но key_len то 3 байта. значить сработал только часть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2015, 12:03:57 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
login_sqlruиндекс вы создали и mysql его использует, но key_len то 3 байта. значить сработал только часть.Это не так. Часть - используется при операциях связывания/отбора/сортировки... но индекс-то покрывающий, и на самом деле используется весь - просто сведения об использовании покрывающего индекса для экстракции данных нигде и никак не отображаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2015, 12:06:01 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsovНе совсем понял про решение "группировку выделять в предрассчитанную таблицу"?Это значит хранить еще одну таблицу с примерно тем же содержимым, которое получается у в результате подзапроса. Например, из полей (дата, game_id, cnt). Т.е. тот же счетчик, но с разбивкой по дням и играм. ПК - два первых поля. А запрос превратится примерно в такой: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Поддерживать эту таблицу можно двумя способами: 1) INSERT ... ON DUPLICATE KEY UPDATE при каждом событии, которое нужно подсчитывать (т.е. фактически при записи в таблицу game_views). Оперативность практически мгновенная, но замедляется запись событий. 2) Периодически выполнять группирующий подзапрос по сегодняшнему дню и его результатом апдейтить сегодняшние записи в таблице game_stat. Так нет дополнительной задержки при записи событий, но страдает оперативность - появляется задержка от момента события до момента, когда его результат увидят пользователи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2015, 13:52:24 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
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 раза ускорить выполнение проблемного запроса. Спасибо за помощь! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 11:26:40 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
Забыл показать запрос, который получился в результате нашей оптимизации: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. Теперь запрос выполняется в районе 0.150-0.250 сек ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 11:34:13 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsov, а если напрямую сджойнить, без промежуточной материализации - не быстрее будет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 11:38:39 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
tanglirokuznetsov, а если напрямую сджойнить, без промежуточной материализации - не быстрее будет? Я вас не понимаю? По подробней напишите? Разве первоначальный запрос который требовалось оптимизировать не напрямую был сджойнин без материализации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 11:58:57 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsov, в первоначальном запросе было задействовано больше таблиц и присутствовал лимит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 12:04:29 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsov Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 1) ORDER BY в подзапросе не имеет смысла - он всё равно будет проигнорирован. А если его убрать - то подзапрос теряет смысл. 2) Замена звёздочек на список реально необходимых полей способен ускорить запрос, особенно при наличии индексов, совсем особенно - если они покрывающие. Finally: Код: sql 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 12:19:29 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
Akina, автор1) ORDER BY в подзапросе не имеет смысла - он всё равно будет проигнорирован. А если его убрать - то подзапрос теряет смысл. Использование ORDER BY придаёт запросу реальную отсортированную упорядоченную выдачу, при этом он НЕ ИГНОРИРУЕТСЯ, а реально работает, ваши утверждения НЕ ВЕРНЫ! автор2) Замена звёздочек на список реально необходимых полей способен ускорить запрос, особенно при наличии индексов, совсем особенно - если они покрывающие. Я в курсе про звёздочки+поля+индексы (я думаю уже вообще мало людей осталось который не в курсе), но реального ускорения выполнения запроса от использования полей в место звёздочек в данном случае я не увидел, как выполнялся за своё время так и выполняется в этих временных интервалах, при этом уменьшилось число символов в запросе и повысилась читабельность ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 14:16:47 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
tanglirokuznetsov, в первоначальном запросе было задействовано больше таблиц и присутствовал лимит. Во-первых: таблиц задействовано столько же (одну таблицу с более чем 1 000 000 записей заменили на другую в которой всегда 28 записей, которая подзапросом набивается один раз ночью по крону. На этом в скорости и выйграли!) Во-вторых: если что-то хотите посоветовать/подсказать, то делайте это, не нужно отвлекать понапрасну, ФЛУДИТЬ и посты себе набивать какой-то х.... Я тоже умею ПЕРЕСКАЗЫВАТЬ очевидные вещи - это я про "присутствие лимита" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 14:25:39 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsovИспользование ORDER BY придаёт запросу реальную отсортированную упорядоченную выдачу, при этом он НЕ ИГНОРИРУЕТСЯ, а реально работает, ваши утверждения НЕ ВЕРНЫ!Есть определённая категория граждан, которым везёт... но даже им везёт не всегда. Так что когда (не "если", а именно "когда") разобьёшь на этом своём ложном убеждении физиономию - не плачься. okuznetsovЯ в курсе про звёздочки+поля+индексы (я думаю уже вообще мало людей осталось который не в курсе), но реального ускорения выполнения запроса от использования полей в место звёздочек в данном случае я не увиделЗримого ускорения ты не видишь скорее всего потому, что не выполнены все указанные мной условия. Или потому что таблицы у тебя с кукиш размером. Или потому, что ты выполняешь запрос в модельно-эксклюзивных, а не боевых, условиях, когда каждый килобайт оперативки и тик процессора на вес золота. Для повышения читабельности запроса используют его форматирование. А экономия байтов... тебе что, приплачивают за неё, что ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 14:25:44 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsov, Это правильный запрос (в принципе можно и без ORDER BY обойтись, но тогда выводимые игры на странице будут не отсортированы по популярности, если кому нужна такая выдача, то пожалуйста я не против. В данном случае по проведённым мной тестам без ORDER BY - ни как не повлияло на скорость выполнения запроса) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 14:31:58 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
Akina, Не забывайте как моя тема называется: "требуется помощь в оптимизации запроса", подразумевается, что не кому-то, а именно мне нужно помочь, и именно в моих условиях и на моих объёмах данных - запрос ускорить. okuznetsovИспользование ORDER BY придаёт запросу реальную отсортированную упорядоченную выдачу, при этом он НЕ ИГНОРИРУЕТСЯ, а реально работает, ваши утверждения НЕ ВЕРНЫ!Есть определённая категория граждан, которым везёт... но даже им везёт не всегда. Так что когда (не "если", а именно "когда") разобьёшь на этом своём ложном убеждении физиономию - не плачься.[/quot] Уже ни один раз видел (не помню на каких форумах) похожее высказывание, разумеется не мне адресованное, читал у других. Теперь вот и мне посоветовали. Постараюсь не плакать) Давайте не будем ругаться, в данном случае вы не правы, я вам об этом сказал. Везения здесь нет - на ORDER BY повторюсь в данном случае ОСНОВАНА ЛОГИКА ЗАПРОСА, кстати и вы об этом выше сказали. авторчто не выполнены все указанные мной условия Читайте выше, все ваши предложения/условия я соблюдал и пробовал в реальных условиях Код: sql 1. Размеры таблиц я указал на скриншоте, таблица выросла до таких размеров за 2 года, по расчётам ещё за 5 лет может вырасти на 500% максимум, и я уверен, что это тоже для вас будет кукиш размер. До объёмов таблиц о которых вы говорите и я предполагаю врятли дело дойдёт. авторИли потому, что ты выполняешь запрос в модельно-эксклюзивных, а не боевых, условиях, когда каждый килобайт оперативки и тик процессора на вес золота. Читайте выше и будьте внимательней, где я выполняю запрос. Для повышения читабельности запроса используют его форматирование. А экономия байтов... тебе что, приплачивают за неё, что ли?[/quot] Вы утрируете, нашли к чему цепляться. Понятно же что имеется ввиду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 15:28:26 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsovв данном случае вы не правы, я вам об этом сказал. Везения здесь нет «Муж, упорный в своих намерениях» (© Гораций). Да пожалуйста, оставайтесь и дальше при своём убеждении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 15:38:25 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsov, Akina все-таки скорее прав насчет сортировки в подзапросе. ORDER BY может быть проигнорирован, если нет LIMIT-а. И я устойчиво помню, что видел этот момент в доке. Однако повторно найти пока не получается. Но нашел другое подтверждение - https://blog.hqcodeshop.fi/archives/25-MySQL-5.6-subquery-ORDER-BY-behaviour-changed-from-5.5.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 16:03:27 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 16:07:35 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
А, кстати, если ORDER BY в подзапросе и выполнялся бы реально, JOIN все равно не обязан сохранить эту сортировку. Зависит от метода его выполнения (а начиная с версии 5.6 их стало более одного) и порядка соединения, выбранного оптимизатором. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 16:11:50 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
Угу. Особенно если оптимизатор решит, что спервоначалу надо сканить таблицу game, и только потом кэшированный подзапрос. А при левом связывании это вообще практически гарантировано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2015, 16:41:16 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsovВо-первых: таблиц задействовано столько же (одну таблицу с более чем 1 000 000 записей заменили на другую в которой всегда 28 записей, которая подзапросом набивается один раз ночью по крону. На этом в скорости и выйграли!)Ну тогда см. выше пост Акины. okuznetsovВо-вторых: если что-то хотите посоветовать/подсказать, то делайте это, не нужно отвлекать понапрасну, ФЛУДИТЬ и посты себе набивать какой-то х.... Я тоже умею ПЕРЕСКАЗЫВАТЬ очевидные вещи - это я про "присутствие лимита"Тынц на пост с моим флудом OR GTFO. Пока что "х...." (насчёт ордербай) несёте именно вы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2015, 07:04:26 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
tanglir, Я не понимаю, что вы имеете в виду. Напишите конкретнее, что предлагаете, я попросил вас об этом, но вы продолжили также загадочно отвечать, что и в первом своём посте. Код: sql 1. Код: sql 1. Может быть я туплю уже, но я реально не понимаю из ваших фраз, что вы предлагаете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2015, 12:24:01 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
miksoft, Я понял вас, спасибо за исчерпывающий всё расставляющий на свои места ответ, сейчас полностью согласен со всем. На данный момент на сервере mysql 5.5.31, но в будущем не исключён вариант на 5.6. Хорошо, что сейчас всплыли данные факты, честно говоря не готов был к такому, спасибо за полезную и интересную информацию. Akina, В следующий раз буду более внимателен к вашим ответам/советам, понял, что нужно вам задавать доп. вопросы (т.к. по некоторым моментам сложно понять вашу мысль). Если бы вы аргументировали свою позицию в похожем на miksoft виде, то с моей стороны не возникло ни каких сомнений. Надеюсь, что вы не в обиде на меня. Также хотелось бы сказать - в спорах рождается истина (не помню автора). Хорошая получилась тема на форуме, надеюсь в будущем кому-то окажется полезной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2015, 12:25:33 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
Без 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` ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2015, 12:30:09 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
Если используется стороннее связывание, STRAIGHT_JOIN избыточен. Но и вреда от него не будет никакого. А насчёт "правильнее" - правильность запроса определяется требуемой логикой получения результата, и варьироваться могут только полностью синтаксически эквивалентные запросы. Ваш же последний запрос неэквивалентен ранее опубликованным... Думаю, есть смысл ещё раз, но уже с учётом вышесказанного, чётко, грамотно и однозначно сформулировать задачу. Сейчас её понимание слишком размыто. okuznetsovНадеюсь, что вы не в обиде на меня.Ессессно. У меня есть куча гораздо более увлекательных дел :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2015, 12:46:29 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsovБез order by в данном случае мне необходим, предполагаю, что правильнее LIMIT добавить и RIGHT JOIN? Или всё-таки использовать STRAIGHT_JOIN?Возьмите да попробуйте. Мне кажется, что разница будет на уровне погрешности измерения. И, если я правильно понял, что в LIMIT-е нет необходимости, т.к. в таблице game_views_popular_month нет лишних записей, то зачем тут вообще подзапрос? Почему бы не раскрыть его? Тогда и ORDER BY гарантированно сработал бы, и оптимизатору попроще было бы, да и читать потом такой запрос легче. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2015, 12:50:14 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
okuznetsovМожет быть я туплю уже, но я реально не понимаю из ваших фраз, что вы предлагаете?Акина уже за меня написал: 17871380 . И что значит "загадочно"? Вы спросили, мол, разве первый запрос не был напрямую сджойнен - я и ответил, что в хоть он и был, но в нём были задействованы не только таблицы, используемые в обсуждаемом варианте (уж извините, не понял, что данные по сути остались те же, только в другой форме). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2015, 13:08:55 |
|
||
|
Требуется помощь в оптимизации запроса
|
|||
|---|---|---|---|
|
#18+
Кстати, вот (можно сказать, эталонный) пример , показывающий, к чему может привести использование недокументированных фич. Тоже сортировка, кстати. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2015, 13:20:52 |
|
||
|
|

start [/forum/topic.php?all=1&fid=47&tid=1832962]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
38ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 197ms |
| total: | 303ms |

| 0 / 0 |
