サブストリングとワイルドカードのようなSQL比較のパフォーマンス

2つのテーブルの間でジョイン条件を処理していますが、一致するカラムの1つが値の連結になっています。 tableAのcolumnAをtableBのcolumnBの最初の2文字に結合する必要があります。サブストリングとワイルドカードのようなSQL比較のパフォーマンス

私はこれを処理するために2つの異なるステートメントを開発しましたが、各メソッドのパフォーマンスを分析しようとしました。

方法1：

ON tB.columnB like tA.columnA || '%'

方法2：

は

ON substr(tB.columnB,1,2) = tA.columnA

クエリ実行プランは、方法2に比べ方法1使用してはるかに少ないステップを持っている、しかし、それは方法2のように見えるが多くを実行しますもっと早く。また、実行計画は、パフォーマンスを向上させる方法2の推奨インデックスを示しています。

私はこれをIBM iSeries上で実行していますが、SQLクエリの最適化の詳細については一般的な意味での解答に関心があります。

方法2がより高速に実行されることは意味がありますか？

これはよく似ていますが、これらのアプローチのパフォーマンスの違いについて具体的な回答を誰も提供してくれなかったようです。T-SQL speed comparison between LEFT() vs. LIKE operator

PS：このタイプの結合が必要な表の設計は、私が現時点で変更できるものではありません。私は、異なるタイプのデータを保持するフィールドを分けておくことが好ましいことを理解しています。

出典

2011-09-15 Swoop

INNERまたはOUTER JOIN？ –

これは内部結合のためのものです。タイプに参加すると違いが出ますか？ – Swoop

クエリオプティマイザで何が起こっているのかを推測するのはおそらく失われたゲームです。しかし、はい、この場合、それがINNER JOINの場合、方法1ではすべてのtAを読み取る必要があり、一方、方法2ではtBを読み取る必要があります。行数に応じて、それは重要であり、実行計画に影響する可能性があります。 –

このレファレンスは、SQLのパフォーマンスに関するIBMのレッドブックで見つかりました。 SUBSTRスカラー関数は、iSeriesによって最適化された方法で処理できるように思えます。

あなたが最初の文字を検索し、代わりにCQEのをSQEを使用する場合は、等号の左側の符号にスカラー関数の部分文字列を使用することができます。文字列の追加文字を検索する必要がある場合は、さらにスカラ関数POSSTRを使用できます。によって、LIKE述部を複数のスカラー関数に分割することにより、が照会オプティマイザーにSQEを使用させることができます。

http://publib-b.boulder.ibm.com/abstracts/sg246654.html?Open

出典

2011-09-16 12:31:10 Swoop

はい、方法2は高速です。 LIKEは効率的ではありません。

さまざまな手法のパフォーマンスを比較するには、Visual Explainを使用してみてください。 System i Navigatorに埋め込まれています。あなたのシステム接続の下で、データベースを展開し、あなたのRDB名をクリックしてください。右下のペインで、[SQLスクリプトを実行する]オプションをクリックします。 SELECT文を入力し、Visual ExplainまたはRun and Explainのメニューオプションを選択します。視覚的な説明は、あなたのステートメントの実行計画を分解し、利用可能なインデックスを持つあなたのテーブルに見積もられた各パーツのコストを表示します。

出典

2011-09-15 19:28:00 WarrenT

私はクエリを最適化するためにVisual Explainを使用していますが、このツールを最大限に活用する方法を習得しようとしています。あなたはそれに関する高度なドキュメントを知っていますか？これまでの私のGoogle検索では、Visual Explainを読み込む方法のような、基本的な好きなものしか見つかりませんでした。 – Swoop

LIKEは、ワイルドカードが比較文字列の最後にあり、エンジンが比較のために利用可能なインデックスを使用することを理解している場合に、非常に効率的です。 –

@Larryある状況では、オプティマイザはLEFT（）と同等のワイルドカードを理解するでしょうか？より効率的な例があれば教えてください。 – WarrenT

私は私のDB2 LUW 10内のテーブルの1にIBM Data Studioの中にSQL顧問に次のように走りました。1つのデータベース：

SELECT * 
FROM PDM.DB30 
WHERE DB30_SYSTEM_ID = 'XXX' 
    AND DB30_VERSION_ID = 'YYY' 
    AND SUBSTR(DB30_REL_TABLE_NM, 1, 4) = 'ZZZZ'

と

SELECT * 
FROM PDM.DB30 
WHERE DB30_SYSTEM_ID = 'XXX' 
    AND DB30_VERSION_ID = 'YYY' 
    AND DB30_REL_TABLE_NM LIKE 'ZZZZ%'

これら同じインデックス、同じ推定IOコストと同じ推定カーディナリティ、唯一の違いを利用した全く同じアクセス経路が推定され、両方あった合計CPU LIKEのコストは178,343.75でしたが、SUBSTRは197,518.48でした（10％の差）。

両方の累積コストは同じですが、この相違はアドバイザーごとに無視できます。

出典

2014-05-06 17:25:23 earthiverse

データベース内の実際の例を実際に実行することができます。

LIKEはいつもより快適です。

select count(*) from u_log where log_text like 'AUT%'; 
1 row(s) returned : 90ms taken 

select count(*) from u_log where substr(log_text,1,3)='AUT'; 
1 row(s) returned : 493ms taken

出典

2015-12-09 00:35:20 SIDU

サブストリングとワイルドカードのようなSQL比較のパフォーマンス

答えて

関連する問題