Я и мой ёбаный кот на фоне ковра. Войти !bnw Сегодня Клубы
WHERE id NOT IN (тысячи записей из подзапроса) выполняется ну очень долго. Есть ли какой-нибудь волшебный способ сделать быстрее, не меняя логики запроса?
Рекомендовали: @minoru
#2SHCNY / @komar / 2967 дней назад

Временная таблица с индексом по id?

#2SHCNY/39F / @minoru / 2967 дней назад
@minoru Дальше. И что?
#2SHCNY/ALM / @komar --> #2SHCNY/39F / 2967 дней назад

@komar Гм, я что-то неправильное придумал, извини.

#2SHCNY/203 / @minoru --> #2SHCNY/ALM / 2967 дней назад
@minoru Не, ну, может, там мерж какой-нибудь охуительный есть, про который я не знаю.
#2SHCNY/X5Q / @komar --> #2SHCNY/203 / 2967 дней назад

@komar Ты можешь попробовать сделать WHERE EXISTS (подзапрос WHERE главная колонка != id) в надежде, что по главной колонке построится индекс и всё будет летать. Ну, или вынести-таки в отдельную таблицу.

#2SHCNY/4C2 / @minoru --> #2SHCNY/X5Q / 2967 дней назад

@minoru Ой, только я тебе логику сломал.

#2SHCNY/U01 / @minoru --> #2SHCNY/4C2 / 2967 дней назад
@minoru А что индекс? У меня 100% CPU сжирается на сраном сравнении каждого айдишника с миллионом вариантов. Я вообще таки думаю, что без изменения логики не обойтись, но вдруг я про что забыл.
#2SHCNY/69K / @komar --> #2SHCNY/4C2 / 2967 дней назад

@komar Ну, индекс даёт возможность быстро взять запись с нужным значением поля. Если глянуть в индекс, а там для такого значения записи нет — значит, id NOT IN (подзапрос) == true. Так же ведь?

#2SHCNY/905 / @minoru --> #2SHCNY/69K / 2967 дней назад
@minoru Точно. Пойду ковыряться.
#2SHCNY/120 / @komar --> #2SHCNY/905 / 2967 дней назад
@komar > сравнении каждого айдишника с миллионом вариантов. ```where id in (``` был заоптимизирован так не делать например алсо возможно можно прерассчитать эту хуйню раз и навсегда
#2SHCNY/4O3 / @anonymous --> #2SHCNY/69K / 2967 дней назад
@anonymous Я тебя нихуя не понимаю.
#2SHCNY/30O / @komar --> #2SHCNY/4O3 / 2967 дней назад
@komar сорь
#2SHCNY/075 / @anonymous --> #2SHCNY/30O / 2967 дней назад
That's because the index is not really helpful for that kind of query, so the database has to do a full table scan. If the query is (for some reason) slower than a simple "SELECT * FROM TABLE", do that instead and filter the unwanted IDs in the program.
#2SHCNY/Q7A / @krkm / 2967 дней назад
@krkm Ебанашка, я для тебя штуки четыре треда создал, пиздуй туда, здесь уважаемые господа сидят.
#2SHCNY/BKE / @komar --> #2SHCNY/Q7A / 2967 дней назад
@komar уважаемые господа DBA оптимизирующие where not in, окда
#2SHCNY/4PZ / @krkm --> #2SHCNY/BKE / 2967 дней назад
@krkm Логика именно такая: выбрать все, за исключением вот этого. Проблема в том, что «вот этого» дохера, и все CPU уходит на тупое сравнение. Сейчас доделаю вариант с временной таблицей и индексом и отпишусь, помогло чи нет.
#2SHCNY/Z7U / @komar --> #2SHCNY/4PZ / 2967 дней назад
@krkm >устаревший ответ с петух оверфлоу про хуй знает какую субд говорю же, заоптимизировали, емнип в 9.х
#2SHCNY/MGG / @anonymous --> #2SHCNY/Q7A / 2967 дней назад
@komar не знаю что за говно этот ваш SQL но я б сделал из множества ID "за исключением вот этого" поебень типа sparse array из bool-ов и выводил бы все это говно
#2SHCNY/BN1 / @j123123 --> #2SHCNY/Z7U / 2967 дней назад
@j123123 лучше бы на жс писал
#2SHCNY/Q5M / @anonymous --> #2SHCNY/BN1 / 2967 дней назад
@komar помянем
#2SHCNY/DRM / @anonymous --> #2SHCNY/Z7U / 2967 дней назад
@komar Temporary table + WHERE NOT EXISTS работает достаточно быстро, чтобы я не проверял вариант с LEFT JOIN + WHERE ... IS NOT NULL. Отлично.
#2SHCNY/PQ5 / @komar --> #2SHCNY/120 / 2967 дней назад

@komar То есть таки не оптимизировали NOT IN, вопреки утверждениям анонимуса :( Ты на ANALYZE EXPLAIN смотрел, кстати? Там правда всё грустно?

#2SHCNY/MDF / @minoru --> #2SHCNY/PQ5 / 2967 дней назад
@minoru Тут разные анонимусы несут разную хуйню, и проблему, похоже, понял только один ты. Я не знаю, что и как должно быть заоптимизировано.
#2SHCNY/I1T / @komar --> #2SHCNY/MDF / 2967 дней назад

@komar В моём понимании планировщик мог бы и догадаться, что сейчас придётся в результатах подзапроса много раз рыться, и сразу вынести его во временную таблицу и построить индекс.

#2SHCNY/QFM / @minoru --> #2SHCNY/I1T / 2967 дней назад
@minoru пусть лучше письмо начальнику напишет чтоб тот отъебался, он же планировщик
#2SHCNY/KOO / @komar --> #2SHCNY/QFM / 2967 дней назад
Вычесть множество?
#2SHCNY/BT2 / @anonymous / 2967 дней назад
@anonymous Вычесть множество.
#2SHCNY/18J / @komar --> #2SHCNY/BT2 / 2967 дней назад
@komar Я тупой. Minus-то подойдёт в данном случае?
#2SHCNY/9I7 / @anonymous --> #2SHCNY/18J / 2967 дней назад
@anonymous Чего?
#2SHCNY/ZYA / @komar --> #2SHCNY/9I7 / 2967 дней назад
@komar Ну, я всё время забываю, как называется, и гугля "sql set operations". // https://www.udel.edu/evelyn/SQL-Class2/joins.jpg
#2SHCNY/CA8 / @anonymous --> #2SHCNY/1UR / 2967 дней назад

@komar Круто! И что, оно быстрее твоего предыдущего решения?

#2SHCNY/0CB / @minoru --> #2SHCNY/1UR / 2967 дней назад
@minoru Лень проверять, ботлнек уже не там.
#2SHCNY/SGC / @komar --> #2SHCNY/0CB / 2967 дней назад
@krkm - Did you just tell me to go fuck myself? - I believe I did, Bob.
#2SHCNY/YIG / @mugiseyebrows --> #2SHCNY/Q7A / 2967 дней назад
@komar Для тебя все это чудо Для тебя все это мило На тебя глазеют люди На тебя летят витрины
#2SHCNY/UZX / @mugiseyebrows --> #2SHCNY/BKE / 2967 дней назад
@minoru там есть тонкая разница между not in и not exists, когда есть нуллы. А так -- годно.
#2SHCNY/3TL / @gds --> #2SHCNY/905 / 2966 дней назад
ipv6 ready BnW для ведрофона BnW на Реформале Викивач Котятки

Цоперайт © 2010-2016 @stiletto.