SQL「LIKE」の複雑さ

Question

最も一般的なデータベースのSQL LIKE 演算子の複雑さを誰もが知っていますか？

Answer 1

3つのコアケースを個別に検討しましょう。この説明はMySQL固有ですが、インデックスは通常同様の方法で実装されるため、他のDBMSにも適用される場合があります。

LIKE 'foo％' はインデックス付きカラムで実行すると高速です。 MySQLインデックスはBツリーのバリエーションであるため、このクエリを実行すると単純に下降できます。ツリーを foo に対応するノード、またはそのプレフィックスを持つ最初のノードに移動し、ツリーを前方に走査します。これらはすべて非常に効率的です。

LIKE '％foo' はインデックスによって高速化できず、全テーブルスキャンになります。インデックスを使用して実行できる他の基準がある場合、最初のフィルタリング後に残っている行のみをスキャンします。

コツがあります：拡張子が .foo のファイル名を検索するなど、接尾辞の一致が必要な場合は、追加することで同じパフォーマンスを実現できます元の列と同じ内容であるが、文字の順序が逆の列。

ALTER TABLE my_table ADD COLUMN col_reverse VARCHAR (256) NOT NULL;
ALTER TABLE my_table ADD INDEX idx_col_reverse (col_reverse);
UPDATE my_table SET col_reverse = REVERSE(col);

.foo で終わる col の行を検索すると、次のようになります。

SELECT * FROM my_table WHERE col_reverse LIKE 'oof.%'

最後に、ショートカットのない LIKE '％foo％' があります。行の量を実行可能に減らす他の制限条件がない場合数、それはハードパフォーマンスヒットを引き起こします。代わりに、全文検索ソリューション、または他の特殊なソリューションを検討することをお勧めします。

Answer 2

パフォーマンスへの影響について質問している場合：

likeの問題は、データベースがインデックスを使用できないようにすることです。 Oracleでは、インデックスを使用しなくなったと思います（ただし、まだOracle 9を使用しています）。ワイルドカードが最後にのみある場合、SqlServerはインデックスを使用します。他のデータベースについては知りません。

Answer 3

RDBMS、データ（および場合によってはデータのサイズ）、インデックス、およびLIKEの使用方法（プレフィックスワイルドカードの有無にかかわらず）に依存します！

あなたは一般的な質問をしすぎています。