Экспериментальным способом определил, что селект тормозит из за coalesce .
Вот собственно селект который выполняется порядка 12 минут:
1) select d.* from data_9000 d
where d.god=2017 and d.mes=12 and
d.oktmo in (select coalesce(g.code, -1) as code from s_oktmo_g g
where g.oktmo in (select coalesce(s.oktmo,-1) from s_oktmo2017 s where coalesce(s.priz_viborky,0)=1));
А вот этот же селект без coalesce который выполняется меньше чем за 1 секунду.
2) select d.* from data_9000 d
where d.god=2017 and d.mes=12 and
d.oktmo in (select g.code from s_oktmo_g g
where g.oktmo in (select s.oktmo from s_oktmo2017 s where coalesce(s.priz_viborky,0)=1));
у таблицы s_oktmo есть индекс по столбцу oktmo;
у таблицы s_oktmo_g есть индекс по столбцу code и oktmo;
у таблицы data_9000 пока нет индекса, но суть не в этом.
Приложил графики из Performance Analysis левый от первого селекта правый от второго.
ФБ превращает некоррелированный IN в коррелированный EXISTS. При этом внутри подзапроса возникает условие вида d.oktmo = coalesce(g.code, -1) и наличие COALESCE делает невозможным использование индекса по таблице внутри подзапроса.
dimitr, +
Точно так. Проверил свою версию - я был неправ, не поможет.
И наоборот - обрамление поля, используемого в условии IN в coalesce привело к использованию натурального перебора вместо индекса на аналогичного вида запросе.
IN - не наш метод.
Мысли на соединения перескакивают непроизвольно.
Что-то типа такого:
Код: sql
1. 2. 3. 4. 5. 6. 7.
select d.*
from data_9000 d
join (select distinct coalesce(g.code, -1) as code
from s_oktmo2017 s
join s_oktmo_g g on g.oktmo = coalesce(s.oktmo, -1)
where coalesce(s.priz_viborky, 0) = 1) g
on g.code = d.oktmo
спасибо за расъяснение.
Получается лучше избегать таких ситуаций?
А что насчет просто перечислений в in например: oktmo in (1000,1001,1002) - такие перечисления думаю не будут тормозить.
SlobAnспасибо за расъяснение.
Получается лучше избегать таких ситуаций?
А что насчет просто перечислений в in например: oktmo in (1000,1001,1002) - такие перечисления думаю не будут тормозить.
Проблема в ограниченном количестве элементов под оператором in. И в невозможности впихнуть это всё в один запрос. Как было сказано "in - это не наш путь".
