プロが教える店舗&オフィスのセキュリティ対策術

どなたかSQLについてわかる方教えてください。

以前にLike検索は全件検索だから遅いというのを聞いたのですが、

Selectの条件としてWhereに「Like "A%" and Like "B%"」と設定した時と
「Like "A%"」と「Like "B%"」とを設定した処理を2回に分けて検索した時とでは
の検索処理速度的にどちらの方が早いのでしょうか?
あと、サーバの負荷はどちらの方がかかるのでしょうか?

よろしくお願いします。

A 回答 (3件)

> Like "A%" and Like "B%


は成立しない。

レコード数、その列へのIndex付与、統計情報の状態で変わるので、難しいですね。

この回答への補足

回答ありがとうございます。

「 Like "A%" and Like "B%」
は成立しないとのことですが、たしかに良く考えてみれば(^^;

「 Like "A%" or Like "B%」
ならどうなのでしょうか?

レコード数は、数万件規模です。
Like文の検索条件そのものにはIndexは付与されていません。

以上のことを踏まえ再度どうでしょうか?

補足日時:2011/06/08 23:14
    • good
    • 0

「項目 Like 'A%' or 項目 Like 'B%'」の間違いとした場合


基本的に一つのSQLで処理した方が速いでしょう。
・「項目 Like 'A%' 」「項目 Like 'B%'」いずれもINDEXがないなどフルスキャンの場合は、一回のフルスキャンで全データを取得できます。
・「項目 Like 'A%' 」の該当件数、「項目 Like 'B%'」の該当件数が少ない時はそれぞれのINDEXの結果を合わせて取得します。ほとんどの場合はこの処理(=CONCATINATE)は速いと思います。
ただ、「項目 Like 'A%' 」の該当件数+「項目 Like 'B%'」の該当件数の合計でのINDEXアクセスのコストがフルスキャンのコストを上回る可能性もゼロではありません。
必要に応じて /*+ FULL( 表名 ) */ のようにヒント句をつけたほうがいいでしょう。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。

速度的にみると「or」でつなげた方が早そうなんですね。
ただ、以前にサーバに負荷がかかりすぎて他の処理に影響が出たことがあったので、
教えていただいた「 /*+ FULL( 表名 ) */ 」の
ヒント句を使用したりして負荷試験もしてみます。

お礼日時:2011/06/09 11:14

前方一致ならインデックスが効くと思います。


当然、DBMSがそのインデックスを使用する実行計画を選択した場合ですが。

2回SELECTした場合はディスク走査が2回になりそうです。
厳密に言えば、クエリーのパース時間も2回分になるでしょう。

LIKE 'A%' OR LIKE 'B%'の場合はディスク走査はおそらく1回で済みそうです。

キャッシュやバッファ等もあるので、2回実行するからといって、純粋に時間も2倍とはならないでしょうが、LIKE条件をORで結合したほうが速そうな印象はあります。

いずれにしても、現在のサーバー性能で数万件程度のデータ操作なら、大差はないと思います。
ただし、ループ内で実行する等、高頻度で実行するのなら、小さな差も無視できません。

どうしても白黒つけたい場合、想定データ量も分かっているようですし、自分ならテストデータを作って試してみます。一応の根拠にはなりますよね。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。
速度的にみると「or」でつなげた方が早そうなんですね。
ただ、以前にサーバに負荷がかかりすぎて他の処理に影響が出たことがあったので、
テストデータを作成して試してみます。

お礼日時:2011/06/09 11:11

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人はこんなQ&Aも見ています

関連するカテゴリからQ&Aを探す


このQ&Aを見た人がよく見るQ&A