SQL'like 'vs' = 'パフォーマンス

Question 1

この質問は私が疑問に思っていることを回避しますが、答えは正確にそれに対処していません。

一般に、ワイルドカードを使用する場合、「=」は「like」よりも高速であるように見えます。これは一般通念のようです。ただし、限られた数の異なる固定のハードコードされたvarchar識別子を含む列があり、それらの1つに一致するすべての行を選択するとします。

select * from table where value like 'abc%'

そして

select * from table where value = 'abcdefghijklmn'

'Like'は、最初の3文字をテストして一致を見つけるだけでよいのに対し、 '='は文字列全体を比較する必要があります。この場合、「like」には利点があり、他のすべての条件は同じであるように思われます。

これは一般的な学術的な質問として意図されているため、どのDBでも問題ありませんが、SQL Server2005を使用して発生しました。

Question 2

見る https://web.archive.org/web/20150209022016/http://myitforum.com/cs2/blogs/jnelson/archive/2007/11/16/108354.aspxをください

そこからの引用：

LIKEでのインデックス使用のルールは、大まかに次のようになります。

フィルタ条件でequals =が使用され、フィールドにインデックスが付けられている場合、ほとんどの場合、INDEX / CLUSTERED INDEXSEEKが使用されます。

フィルタ条件でワイルドカードを使用せずにLIKEを使用する場合（Webレポートに％が含まれる可能性があるパラメータがあり、代わりに完全な文字列を使用する場合など）、インデックスを使用する可能性はほぼ1位です。コストの増加はほとんどありません。

フィルタ条件でLIKEが使用されているが、先頭にワイルドカードが付いている場合（Name0 LIKE '％UTER'のように）、インデックスを使用する可能性ははるかに低くなりますが、少なくとも次の範囲全体または一部でINDEXSCANを実行できます。インデックス。

ただし、フィルター基準がLIKEを使用しているが、STRING FIRSTで始まり、その後のどこかにワイルドカードがある場合（Name0 LIKE'COMP％ER 'のように）、SQLはINDEX SEEKを使用して、最初に同じ行をすばやく見つけることができます。開始文字を入力し、それらの行を調べて完全に一致するかどうかを確認します。

（また、クエリで他に何が行われているのか、どのテーブルに参加しているのかによっては、SQLエンジンが期待どおりにインデックスを使用しない可能性があることにも注意してください。SQLエンジンは、少しクエリを実行して、最も効率的であり、INDEXSEEKの代わりにINDEXSCANが含まれている可能性があると思われる方法でデータを取得します）

Question 3

それは測定可能な違いです。

以下を実行します。

Create Table #TempTester (id int, col1 varchar(20), value varchar(20))
go

INSERT INTO #TempTester (id, col1, value)
VALUES
(1, 'this is #1', 'abcdefghij')
GO

INSERT INTO #TempTester (id, col1, value)
VALUES
(2, 'this is #2', 'foob'),
(3, 'this is #3', 'abdefghic'),
(4, 'this is #4', 'other'),
(5, 'this is #5', 'zyx'),
(6, 'this is #6', 'zyx'),
(7, 'this is #7', 'zyx'),
(8, 'this is #8', 'klm'),
(9, 'this is #9', 'klm'),
(10, 'this is #10', 'zyx')
GO 10000

CREATE CLUSTERED INDEX ixId ON #TempTester(id)CREATE CLUSTERED INDEX ixId ON #TempTester(id)

CREATE NONCLUSTERED INDEX ixTesting ON #TempTester(value)

次に：

SET SHOWPLAN_XML ON

次に：

SELECT * FROM #TempTester WHERE value LIKE 'abc%'

SELECT * FROM #TempTester WHERE value = 'abcdefghij'

結果の実行プランは、最初の操作であるLIKE比較のコストが、比較よりも約10倍高いことを示してい=ます。

=比較できる場合は、ぜひ行ってください。

Question 4

また、を使用する場合like、一部のSQLフレーバーはインデックスを無視し、パフォーマンスが低下することにも注意してください。これは、例のように「startswith」パターンを使用しない場合に特に当てはまります。

クエリの実行プランを実際に見て、クエリが何をしているのかを確認し、できるだけ推測しないようにする必要があります。

そうは言っても、「で始まる」パターンはSQLサーバーで最適化できます。それはなりますテーブルインデックスを使用します。EF 4.0に切り替えるlikeためのStartsWith、まさにこの理由のために。

Question 5

valueがインデックス付けされていない場合、両方ともテーブルスキャンになります。このシナリオでのパフォーマンスの違いはごくわずかです。

valueダニエルがコメントで指摘しているように、がインデックス付けされている場合、=はO（log N）パフォーマンスであるインデックスルックアップになります。LIKEをします-インデックスの部分スキャンでは（ほとんどの場合、それがどのように選択的に依存する）結果>= 'abc'と< 'abd'これ以上の努力が必要になります=。

ここではSQLServerについて話していることに注意してください。すべてのDBMSがLIKEに適しているわけではありません。

Question 6

あなたは間違った質問をしている。データベースでは、重要な作業のパフォーマンスではありません常にSARGability表現、および被覆性全体的なクエリの。オペレーター自体のパフォーマンスはほとんど関係ありません。

では、SARGabilityの観点からどのようLIKEに=比較しますか？LIKE、定数で始まらない式で使用される場合（たとえば、使用される場合LIKE '%something'）は、定義上、非SARGabaleです。しかし、=それはLIKE 'something%'SARGableになりますか？いいえ。SQLのパフォーマンスに関する質問と同様に、答えはテキストのクエリではなく、展開されたスキーマにあります。これらの式は、次の場合にSARGableになる可能性があります、それらを満たすためのインデックスが存在する、ます。

だから、真実は言われます、との間には小さな違いが=ありますLIKEます。しかし、SQLで1人のオペレーターと他のオペレーターのどちらが「速い」かを尋ねるのは、「赤い車と青い車のどちらが速くなるのか」と尋ねるようなものです。色ではなく、エンジンのサイズと車両の重量について質問する必要があります...リレーショナルテーブルの最適化に関する質問に取り組むには、WHERE句（およびその他の句）のインデックスと式を確認しますが、通常はWHEREで始まります）。

Question 7

mysql 5.5を使用した個人的な例：300万行の1つと1万行の1つである2つのテーブル間に内部結合がありました。

以下のようなインデックスでlikeを使用する場合（ワイルドカードなし）、約30秒かかりました。

where login like '12345678'

'explain'を使用すると、次のようになります。

ここに画像の説明を入力してください

同じクエリで「=」を使用する場合、約0.1秒かかりました。

where login ='600009'

'explain'を使用すると、次のようになります。

ここに画像の説明を入力してください

ご覧のとおりlike、インデックスシークが完全にキャンセルされたため、クエリに300倍の時間がかかりました。

Question 8

多分あなたは全文検索について探しています。

全文検索とは対照的に、LIKETransact-SQL述語は文字パターンでのみ機能します。また、LIKE述部を使用して、フォーマットされたバイナリデータをクエリすることはできません。さらに、大量の非構造化テキストデータに対するLIKEクエリは、同じデータに対する同等のフルテキストクエリよりもはるかに低速です。数百万行のテキストデータに対するLIKEクエリは、返されるまでに数分かかる場合があります。一方、フルテキストクエリは、返される行数に応じて、同じデータに対して数秒以下しかかかりません。

Question 9

まず最初に、

それらは常に等しいとは限りません

    select 'Hello' from dual where 'Hello  ' like 'Hello';

    select 'Hello' from dual where 'Hello  ' =  'Hello';

物事が常に等しいとは限らない場合、それらのパフォーマンスについて話すことはそれほど重要ではありません。

文字列とchar変数のみで作業している場合は、パフォーマンスについて話すことができます。ただし、一般的に交換可能であるため、likeと "="は使用しないでください。

多くの投稿（上記および他の質問）で見たように、それらが等しい場合、パターンマッチング（照合）のためにlikeのパフォーマンスが遅くなります