Как оптимизировать SQL запрос, чтобы SUМ не считалась до конца?

Question

[Сергей Еремин]

В база простая, каскадная организация данных: table3 --> table2 --> table1. Т.е. table3 связана форенкеем с table2, которая в свою очередь связана форенкеем с table1. В table3 есть булево поле bExported, которое сигнализирует была-ли данная запись экспортирована в другую БД.

И вот я хочу получить такие записи из table1, чтобы у них "в связке" была хоть одна ещё не экспортированная запись: table3.bExported = FALSE.

Мне показалось разумным просуммировать все "связанные" bExported, и если эта сумма меньше общего числа записей той-же выборки, то получу искомое:

SELECT
  table1.*
FROM table3
  INNER JOIN table2
    ON table3.tab2_id = table2.id
  INNER JOIN table1
    ON table2.tab1_id = table1.id
GROUP BY
         table1.id,
         table1.datas
HAVING SUM(table3.bExported) < COUNT(table3.id)

Но записей в table3 -- полмиллиарда и перебрать их все, сделать SUM и COUNT --не быстро... На самом деле даже HAVING SUM(table3.bExported) > 0 -- выполняется на тоже время, хотя казалось бы догадаться, что как только SUM(table3.bExported) станет равным единице уже можно дальше не сканировать таблицы, ведь table3.bExported -- логическая и в ней не может быть отрицательных чисел...

И вот не понимаю, как это оптимизировать. В действительности же не нужно ничего "складывать" и "пересчитывать"... Нужно просто найти хоть одну table3.bExported = FALSE и этого достаточно. Причём table3.bExported -- имеет индекс и найти это быстро...

Но как написать такой запрос?...

P.S. Совсем идеально если такой запрос упасться записать на Django-ORM... Но, по-моему, это уже из области фантастики...

Answer 1

[idShura]

Уберите
HAVING SUM(table3.bExported) < COUNT(table3.id)

И добавьте
WHERE table3.bExported = FALSE

Comments

[Сергей Еремин]

Тоже долго... Ведь все равно все таблицы джойнятся и проверяются условия для всего полмиллиарда записей ... Нужно придумать, чтоб проверка table3.bExported = FALSE выполнялась до первого совпадения...

[Сергей Евсюков]

В конце добавьте LIMIT 1. Может поможет)

[Сергей Еремин]

Тогда выдаст только одну запись, а мне нужно все... И LIMIT 1 ускорение не очень даёт. Все равно же надо всю финальную таблицу построить чтоб найти в ней первую запись...

Медленно даже вот так:

SELECT
  table1.*
FROM table3
  INNER JOIN table2
    ON table3.tab2_id = table2.id AND table3.bExported = FALSE
  INNER JOIN table1
    ON table2.tab1_id = table1.id
GROUP BY
         table1.id,
         table1.datas

Потому, что записей с table3.bExported = FALSE тоже сотни миллионов...

Пробовать вложенные запросы? Но не соображу как сделать запрос, чтоб при нахождении первой записи с условием table3.bExported = FALSE дальше таблицы не сканировались... :(

[idShura]

Сергей Еремин, Вы хоть план выполнения запроса прикладывайте.

[idShura]

Сергей Еремин, Скорее всего GROUP BY вам не нужен, попробуйте использовать DISTINCT.
Также как и писал выше, уберите HAVING и добавите WHERE table3.bExported = FALSE.
Также неплохо бы посмотреть план этого запроса.

[Сергей Еремин]

idShura, Чтобы показать план запроса надо его выполнить.... А он выполняется часами!

Сейчас по вашей наводке тестирую вот такую версию:

SELECT DISTINCT
  table1.*
FROM order_tborder
  INNER JOIN table2
    ON table3.tab2 = table2.id AND table3.bExported = FALSE
  INNER JOIN table1
    ON table2.tab1_id = table1.id
WHERE table3.bExported = FALSE

ДОЛГО! По сути DISTINCT никакого ускорения тут не даст. В данном случае он повторит функционал GROUP BY ...