Проблемка в GROUP BY

А то страшно представить что будет происходить когда база разрастется

как только добавляем аггрегацию - попадаем на using temporary & join buffer.

чёт запросики у тебя так себе

как только добавляем аггрегацию - попадаем на using temporary & join buffer.

Прикинь в базе будет несколбко десятков миллионов строк на твою выборку

И-мен-но :)

Собственно почему и спрашиваю

Как бы желаемое что один запрос что другой выдаёт

Как бы желаемое что один запрос что другой выдаёт

Ну тогда наслаждайся

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

я бы на твоем месте не был так уверен что твой сабквери работает

ты видешь где-нибудь в эксплейне derived table ?

если нет derived table - значит запрос был оптимизирован с помощью derived_merge, а это в большинстве случаев говно-оптимизация

Таки не вижу

ну вот...

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

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

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

Это если по нормальному проектировать, в данном случае это просто задачка

Это если по нормальному проектировать, в данном случае это просто задачка

Как привыкнешь так и будешь потом делать.

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

А лучше и то и другое

а лучше машку за ляшку

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

Хы))

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

Причем в наивной же реализации

все равно шляпа

type = index читай как фуллскан

Фуллскан индекса, который вероятно валяется в индекс-буфере - это лучше чем фуллскан таблицы

это на чуть-чуть лучше чем all но все равно шляпа

Тоже правда, помнится некоторые индексы весят сравнимо с данными

Тоже правда, помнится некоторые индексы весят сравнимо с данными

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

Ну вычислимые поля, да - но я таки не зря birthdate поставил последним

так именно он у тебя и не будет использоваться :)

Я делаю выборку и сортирую, например, по уровню (level). Можно ли узнать, на каком месте стоит юзер с айди, например, 5? Постгря

Маразм крепчает

@Frank_Einstein вообще, если уж по делу говорить - запрос у тебя должен быть быть вот такой: SELECT a.id as a_id, SUM(l.amount), COUNT(*) FROM account a JOIN loan l ON l.account_id = a.id WHERE a.sex = 2 AND a.birthday BETWEEN UNIX_TIMESTAMP(NOW - INTERVAL 30 YEAR) AND UNIX_TIMESTAMP(NOW - INTERVAL 20 YEAR) GROUP BY 1 ORDER BY NULL и уже потом ты навешиваешь все необходимые тебе поля по фамилиям и прочим данным, чем меньше объем данных ты группируешь и сортируешь и вообще держишь во внутренней временной таблице во время запроса - тем лучше

Друзья-товарищи, а вот вопрос - имеем данные-запрос вот такого вида: https://www.db-fiddle.com/f/mZrc6Ws5Be28FXns9A98b8/1 Что-то я уже извёлся пытаясь избавиться от Using temporary в первой строчке эксплейна. И - да, выглядит адово, но это всё ради оптимизации наворочано. Сама выборка там довольно простая, но вылазит в temporary & filesort если делать по-простому

В file sort самом по себе нет ничего плохого.

Я кстати немного поизвращался с force index, но такое себе)

В file sort самом по себе нет ничего плохого.

ага, если только он не внутренний на диске

@Frank_Einstein вообще, если уж по делу говорить - запрос у тебя должен быть быть вот такой: SELECT a.id as a_id, SUM(l.amount), COUNT(*) FROM account a JOIN loan l ON l.account_id = a.id WHERE a.sex = 2 AND a.birthday BETWEEN UNIX_TIMESTAMP(NOW - INTERVAL 30 YEAR) AND UNIX_TIMESTAMP(NOW - INTERVAL 20 YEAR) GROUP BY 1 ORDER BY NULL и уже потом ты навешиваешь все необходимые тебе поля по фамилиям и прочим данным, чем меньше объем данных ты группируешь и сортируешь и вообще держишь во внутренней временной таблице во время запроса - тем лучше

Логично. Гм, щас затестим, спасибо

@Frank_Einstein вообще, если уж по делу говорить - запрос у тебя должен быть быть вот такой: SELECT a.id as a_id, SUM(l.amount), COUNT(*) FROM account a JOIN loan l ON l.account_id = a.id WHERE a.sex = 2 AND a.birthday BETWEEN UNIX_TIMESTAMP(NOW - INTERVAL 30 YEAR) AND UNIX_TIMESTAMP(NOW - INTERVAL 20 YEAR) GROUP BY 1 ORDER BY NULL и уже потом ты навешиваешь все необходимые тебе поля по фамилиям и прочим данным, чем меньше объем данных ты группируешь и сортируешь и вообще держишь во внутренней временной таблице во время запроса - тем лучше

Что самое забавное, план получается аналогичный :)

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

Увы, обычный db-fiddle

вся вот эта вот дичь с вебмордой делается в докере за 5 минут с перекуром

Друзья-товарищи, а вот вопрос - имеем данные-запрос вот такого вида: https://www.db-fiddle.com/f/mZrc6Ws5Be28FXns9A98b8/1 Что-то я уже извёлся пытаясь избавиться от Using temporary в первой строчке эксплейна. И - да, выглядит адово, но это всё ради оптимизации наворочано. Сама выборка там довольно простая, но вылазит в temporary & filesort если делать по-простому

А можно ещё раз запрос, на пасту бина...?

ERROR: S client not available

А можно ещё раз запрос, на пасту бина...?

https://www.db-fiddle.com/f/hMeiFEvuEz5D65CoG3bbkK/0

И все варианты решения, тот который раскомментирован - lost soul, два остальных мои.

Собсна у первых двух план в целом одинаковый - у третьего почудовищнее

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

Кстати на тему тулзы) А какие варианты? У меня в основном datagrip встроенный в IDE джетбрейнсовскую, у него вроде тот же самый набор

я имел ввиду что сама эта вебморда предоставляет не полный функционал

версия мускуля 5.7, explain format = json не сделать, почему? а хрен его знает почему...

норм тулза, пацаны

взял и сервер (не дай бог) отправил погулять

Дык докер-песочница тоже поди

возможно

Если нет - зря :)

Ну кстати))

Format=json я таки сделал там

v 5.6 правда только

все-таки да, контейнер

везёт им

ты сегодня немногословен

Я делаю выборку и сортирую, например, по уровню (level). Можно ли узнать, на каком месте стоит юзер с айди, например, 5? Постгря

может кто помочь?

может кто помочь?

мы же уже обсуждали раз. помощь это когда ты делаешь и тебе помогают исправить ошибки а ты хочешь что бы за тебя сделали, и это уже РАБОТА, за нее в кассу :)

мы же уже обсуждали раз. помощь это когда ты делаешь и тебе помогают исправить ошибки а ты хочешь что бы за тебя сделали, и это уже РАБОТА, за нее в кассу :)

это вообще отдельная задача. Мне бы метод подсказать хватит, остальное сам додумаюсь

это вообще отдельная задача. Мне бы метод подсказать хватит, остальное сам додумаюсь

так ты начни додумывать и потом тебе подскажут