Нужно ли рефакторировать эту инструкцию SQL?

SELECT DISTINCT group_id 
     , supplier_id 
     , supplier_name 
     , site_division_id 
     , site_division_name 
FROM view_supplier_site 
WHERE supplier_id IN (SELECT DISTINCT supplier_id 
         FROM view_supplier 
         WHERE YEAR IN (2008, 2009) 
         AND received_quantity > 0 
         AND COE_SUPPLIER NOT IN ('X - LG', 'Y - LG', 'Z - LG'))

источник

2009-10-28 HanuAthena

Страшный DISTINCT. Чем более уместным будет вопрос, почему вы считаете, что это заявление нужно реорганизовать? –

Ничего плохого в 'DISTINCT' - план объяснения покажет, что он идентичен использованию' GROUP BY'. –

Это заявление занимает значительное количество времени, чтобы результат появился. Просто нужно было знать, является ли это проблемой с оператором SQL или связано с большим количеством записей в таблице ??? – HanuAthena

Non Subquery Факторинг:

SELECT vss.group_id, 
     vss.supplier_id, 
     vss.supplier_name, 
     vss.site_division_id, 
     vss.site_division_name 
    FROM view_supplier_site vss 
    JOIN (SELECT vs.supplier_id 
      FROM view_supplier vs 
      WHERE vs.year IN (2008, 2009) 
      AND vs.received_quantity > 0 
      AND vs.coe_supplier NOT IN ('X - LG', 'Y - LG', 'Z - LG') 
     GROUP BY vs.supplier_id) s ON s.supplier_id = vss.supplier_id 
GROUP BY vss.group_id, vss.supplier_id, vss.supplier_name, vss.site_division_id, vss.site_division_name

Использование подзапросов факторинг:

WITH suppliers AS (
    SELECT vs.supplier_id 
     FROM view_supplier vs 
    WHERE vs.year IN (2008, 2009) 
     AND vs.received_quantity > 0 
     AND vs.coe_supplier NOT IN ('X - LG', 'Y - LG', 'Z - LG') 
    GROUP BY vs.supplier_id) 
    SELECT vss.group_id, 
     vss.supplier_id, 
     vss.supplier_name, 
     vss.site_division_id, 
     vss.site_division_name 
    FROM view_supplier_site vss 
    JOIN suppliers s ON s.supplier_id = vss.supplier_id 
GROUP BY vss.group_id, vss.supplier_id, vss.supplier_name, vss.site_division_id, vss.site_division_name

Они эквивалентны.

До сих пор, как я вижу, нет большой оптимизации. Следующая вещь, чтобы посмотреть на бы индексы ...

источник

2009-10-28 05:30:49

wow !! похлопывание по спине, чувак. Ваш «Неподзапрос» просто потребовался 3,5 секунд (avg) для выполнения, в то время как мое заняло около 14 секунд. – HanuAthena

Я ожидаю, что они будут оптимизированы для почти одного и того же плана выполнения, кроме использования DISTINCT (который CBO, вероятно, применит к подзапросу в кепсионе OP efven, если он не был указан). Было бы интересно увидеть планы выполнения для 3,5 сек и 14 сек запросов, чтобы понять, где разница. –

Я хотел бы предложить следующее:

Вместо использования IN, использовать внутреннее соединение (вероятно, не улучшение производительности, но выглядит утверждение " лучше ")
Это позволит вам избавиться от DISTINCT на view_supplier (опять-таки, наверное, нет разницы в производительности)
является DISTINCT на view_supplier нужен? Есть несколько идентификаторов, которые могут быть ключом для поставщика_сайта.
NOT IN может быть проблемой с производительностью .. можете ли вы изменить это на что-то еще, например <'X - LG'?
Если представления больше, чем просто «псевдонимы» для базовых таблиц/столбцов, могут быть способы использования базовых таблиц.
Еще одна вещь, на которую нужно обратить внимание, - это индексы.
Является ли рассчитанная колонка? Если это просто YEAR(datevalue) это может быть быстрее использовать что-то вроде datevalue between <Jan1st> and <Dec31>

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

источник

2009-10-28 05:33:22 Thorsten

Нужно ли рефакторировать эту инструкцию SQL?

ответ

Смежные вопросы