есть или best practice?
Сам запрос: https://pastebin.com/nfVimykw
Его план исполнения на СУБД (получен с помощью EXPLAIN ANALYZE): https://explain.tensor.ru/archive/explain/984b6e797791f2879921530ba00d5b61:0:2021-04-23
СУБД Postgresql 12.5
И точно такой же запрос, но без count, а уже с данными:
Запрос: https://pastebin.com/mKA8ugwc
План: https://explain.tensor.ru/archive/explain/c96830824f38b3e04eeacff20acd8f21:0:2021-04-23
Я вижу предупреждения на explain tensor, но чет пока не догоняю как поправить, если кто-то подскажет - буду признателен.
Его не ускорять, его переписывать надо, IMNSHO. Что вот это за ерунда? AND skuentity1_.id IN ( SELECT skuentity2_.id FROM pim.sku skuentity2_ WHERE skuentity2_.sku_super_model_id = skusupermo0_.id LIMIT 1 -- WTF? Где ORDER BY (или что это вообще должно было значить)? ) и это: WHERE skusupermo0_.id IN ( SELECT DISTINCT skusupermo5_.id ...
балин, походу не тот запрос скинул (это касательно первого пункта, там не должно быть LIMIT. Готовился, готовился и лопухнулся. Но подозреваю, что лучше от этого не станет (сейчас вроде правильный): https://pastebin.com/hPenbGDi Указанный в первом пункте момент изменен на: (skuentity1_.id IN (SELECT MIN(skuentity2_.id) FROM pim.sku skuentity2_ WHERE skuentity2_.sku_super_model_id=skusupermo0_.id))) Суть - взять первый идентификатор (по одной skusupermo0_ может быть много skuentity2_, а мне нужна одна, чтобы по ней одной потом запросить ее наименование. По второму пункту: Это отбор из заранее подготовленного запроса с перечнем идентификаторов для пагинации. Выглядит ужасно?
возможно тяжело изъясняюсь (точнее меня тяжело понять). Попытаюсь объяснить: В WHERE skusupermo0_.id IN ( SELECT DISTINCT skusupermo5_.id ... подбираются все skusupermo5_, которые подходят под фильтры и сортировки переданного пользователем запроса (т. к. не получилось собрать один запрос для этого).
Показали бы всё это снова, в таком случае. > взять первый идентификатор А почему первый-то (ради любопытства)? > Выглядит ужасно? Да. LEFT JOIN внутри IN или EXISTS обычно совершенно излишни (т.к. они не отбрасывают никаких записей, и количество / состав множества skusupermo5_.id, по которым будет выполняться фильтрация, изменить тупо не могут). Т.е. это низкокачественный код, который стоит переписать, а не оптимизировать, опять-таки. ;(
Я подготовлю примеры ещё раз и сброшу, чтобы была целостная картина, только чуть попозже (не за компом сейчас). Заодно поразмышляю над тем, как можно упростить запрос. В любом случае огромное спасибо за комментарий.
Обсуждают сегодня