SQL組合が参加し、高速ですが、クエリプランは、より多くのI/O

Question

select id, c.name as name 
from a join b on a.id=b.id 
join c on a.id=c.id 
union 
select id, d.name as name 
from a join b on a.id=b.id 
join d on a.id=d.id 

コストがクエリの応答時間が13secsに30secsから改善した

select id, 
     case when c.name is not null or c.name <> '' then c.name 
     else d.name end as name 
from a join b on a.id=b.id 
left join c on a.id=c.id 
left join d on a.id=d.id 
where c.name is not null or d.name is not null 

に最適化されたと言います。

• ：
  • SQL組合= 30secs
  • SQLが= 13secs
  、SQL組合は、低I/Oコストを持つクエリプランをチェックする時に

  ただし、以下を参照してください参加左sql union =ステートメント1（行1）の推定I/Oコスト合計：6277566.

• sql left join =ステートメント1（行1）の推定I/Oコストの合計：10481124.

私はSybase 12.5 ASEを使用しており、クエリプランはDBArtisan 8.5からのものでした。クエリプラン全体をアップロードする必要があるかどうかを教えてください。私はまだクエリープランに精通しているわけではありませんが、ここではSQLの最適化を行いますが、通常は時間の改善に基づいています。また、結果セットが両方のクエリ（27949行）で同じであることを確認しました。また、テーブル名を隠して簡略化しました。

私の質問は、SQLの左結合は高速ですが、よりリソース集中型であることを意味しますか？もしそうなら、私はまだより速い選択肢を選択すべきですか？

Answer 1

データベースは内部的にキャッシュを行うため、実行時間は必ずしも最良の指標ではありません。最初のクエリを実行してすぐ後に2番目のクエリを実行すると、データの一部がキャッシュされる可能性があるため、2番目のクエリは不公平なメリットがあります。

データベースのチューニングに関するすべての質問と同様、実際には何も設定されていません。私は個人的にはユニオンが好きですが、パフォーマンスの観点からは厳密には読みやすいと思っています。キャッシングの影響を最小限に抑えるために、長期間にわたってテストを行い、パフォーマンスを確認します。

これらのテーブルにはどのくらいのデータがありますか？ 4つのテーブルのidカラムにインデックスがありますか？もしそうでなければ、それはSQLへの変更をさらに増やします。