オプティマイザーはこれを正しく処理する必要がありますが、元のクエリのパフォーマンスを次のクエリと比較することをお勧めします。
select distinct
c.company_name,
o.outlet_name,
o.outlet_fce_id,
ug.usergroup_name
from company c
inner join (select distinct company_id, outlet_id, username from purchase_invoice) i on c.company_id=i.company_id
inner join outlet o
on i.outlet_id = o.outlet_id
and i.company_id = o.company_id
inner join ot_user u on b.username = e.username
inner join user_group ug on u.usergroup_id = d.usergroup_id
purschases テーブルの個別化により、いくつかの作業が省略される可能性がありますが、それほど多くの重複があるかどうかは疑問です。
さらに役立つのは、のインデックスpurchase_invoice (username, outlet_id, company_id)
です。これは、テーブルのカバリング インデックスになるため、速度が向上する可能性があります。結合はインデックスを確認するだけで済み、実際のテーブルの読み取りをスキップできます。テーブルが広い場合に役立ちます。
また、インデックス内の列の順序にも注意してください。これにct_user
も多くの行があり、クラスター化されたインデックスがあると推測していUsername
ます。このようにして、インデックスとct_user
ユーザー名の両方がソートされ、2 つの大きなテーブルを結合するマージ結合が可能になります。
また、c fr company や user_group の ug など、結合構文と意味のあるエイリアスをテーブルに使用してください。データベースにとっては問題ではありませんが、人間がコードを読み取ろうとするのに役立ちます。また、allcaps はいつもあなたが叫んでいるように見えますが、それは私だけかもしれません :-)
GJ