sql - このSQLステートメントをリファクタリングする必要がありますか？

Question

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') ) 

Answer 1

非サブクエリファクタリング：

  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 

それらは同等です。

私が見る限り、必要な最適化はそれほど多くありません。次に注目するのはインデックスです...

Answer 2

私は次のことを提案します：

• を使用する代わりにIN、内部結合を使用します（おそらくパフォーマンスの向上ではありませんが、ステートメントは「より良い」ように見えます）
• DISTINCTこれにより、 on view_supplierを取り除くことができます（ここでも、おそらくパフォーマンスの違いはありません）
• view_supplierのDISTINCTが必要ですか？supply_siteのキーとなる可能性のあるIDがいくつかあります。
• NOT INパフォーマンスの問題かもしれません..これを他のようなものに変更できます<'X - LG'か？
• if the views are more than just "aliases" for the base tables/columns, there may be ways of using the underlying tables.
• Another thing to look at would be indexes.
• Is YEAR a calculated column? If it is just YEAR(datevalue) it may be faster to use something like datevalue between <Jan1st> and <Dec31>

Most of these changes would be cosmetic, the areas on what to focus on would be determined by the problems you see with the statement.