Gleich(=) vs. LIKE

Question

Gibt es bei der Verwendung von SQL irgendwelche Vorteile bei der Verwendung von = in einem WHERE Klausel anstelle von LIKE ?

Ohne spezielle Operatoren, LIKE y = sind die gleichen, richtig?

Answer 1

Hängt vom Datenbanksystem ab.

Wenn keine Sonderzeichen verwendet werden, sind = und LIKE im Allgemeinen dasselbe.

Einige Datenbanksysteme können jedoch die Sortiereinstellungen mit den verschiedenen Operatoren unterschiedlich behandeln.

In MySQL beispielsweise wird bei Vergleichen mit = bei Zeichenketten standardmäßig die Groß-/Kleinschreibung nicht beachtet, so dass LIKE ohne Sonderzeichen dasselbe ist. Bei einigen anderen RDBMS ist LIKE unabhängig von der Groß- und Kleinschreibung, während = nicht unterschieden wird.

Answer 2

Für dieses Beispiel gehen wir davon aus, dass varcharcol nicht enthält '' und keine leere Zelle in dieser Spalte haben

select * from some_table where varcharCol = ''
select * from some_table where varcharCol like ''

Das erste Ergebnis ist die Ausgabe von 0 Zeilen, während das zweite die gesamte Liste anzeigt. = ist ein Fall von strikter Übereinstimmung, während like wie ein Filter wirkt.

like - arbeitet aufgrund seines Zwecks etwas langsamer und ist für die Verwendung mit varchar und ähnlichen Daten gedacht.

Answer 3

Durch die Verwendung von = werden Platzhalter- und Sonderzeichenkonflikte in der Zeichenfolge vermieden, wenn Sie die Abfrage zur Laufzeit erstellen.

Dies macht dem Programmierer das Leben leichter, da er nicht alle speziellen Platzhalterzeichen ausblenden muss, die sich in der LIKE-Klausel verirren und nicht das gewünschte Ergebnis liefern könnten. Schließlich ist = das 99%ige Anwendungsszenario, und es wäre mühsam, sie jedes Mal auszublenden.

rollt mit den Augen über die 90er Jahre

Ich vermute auch, dass es ein wenig langsamer ist, aber ich bezweifle, dass es signifikant ist, wenn es keine Platzhalter im Muster gibt.

Answer 4

Wenn Sie nach einer genauen Übereinstimmung suchen, können Sie sowohl = als auch LIKE verwenden.

Die Verwendung von "=" ist in diesem Fall ein klein wenig schneller (Suche nach einer exakten Übereinstimmung) - Sie können dies selbst überprüfen, indem Sie dieselbe Abfrage zweimal in SQL Server Management Studio ausführen, einmal mit "=", einmal mit "LIKE" und dann mit der Funktion "Abfrage" / "Tatsächlichen Ausführungsplan einbeziehen".

Führen Sie die beiden Abfragen aus und Sie sollten Ihre Ergebnisse zweimal sehen, plus die beiden tatsächlichen Ausführungspläne. In meinem Fall wurden sie zu 50 % und zu 50 % aufgeteilt, aber der "="-Ausführungsplan hat geringere "geschätzte Teilbaumkosten" (die angezeigt werden, wenn Sie mit dem Mauszeiger über das linke "SELECT"-Feld fahren) - aber auch hier ist der Unterschied nicht wirklich groß.

Aber wenn Sie anfangen, mit Platzhaltern in Ihrem LIKE-Ausdruck zu suchen, wird die Suchleistung nachlassen. Die Suche "LIKE Mill%" kann immer noch recht schnell sein - SQL Server kann einen Index für diese Spalte verwenden, wenn es einen gibt. Die Suche "LIKE %ausdruck%" ist furchtbar langsam, da SQL Server diese Suche nur durch eine vollständige Tabellendurchsuchung erfüllen kann. Seien Sie also vorsichtig mit Ihren LIKE's!

Marc

Answer 5

Um die ursprüngliche Frage nach der Leistung zu beantworten, geht es um Folgendes Indexnutzung . Bei einem einfachen Tabellenscan sind "LIKE" und "=" identisch . Wenn Indizes beteiligt sind, ist es hängt wie die LIKE-Klausel gebildet wird. Genauer gesagt, an welcher Stelle befindet sich der Platzhalter bzw. die Platzhalter?

---

Bedenken Sie Folgendes:

CREATE TABLE test(
    txt_col  varchar(10) NOT NULL
)
go

insert test (txt_col)
select CONVERT(varchar(10), row_number() over (order by (select 1))) r
  from master..spt_values a, master..spt_values b
go

CREATE INDEX IX_test_data 
    ON test (txt_col);
go 

--Turn on Show Execution Plan
set statistics io on

--A LIKE Clause with a wildcard at the beginning
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col like '%10000'
--Results in
--Table 'test'. Scan count 3, logical reads 15404, physical reads 2, read-ahead reads 15416, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index SCAN is 85% of Query Cost

--A LIKE Clause with a wildcard in the middle
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col like '1%99'
--Results in
--Table 'test'. Scan count 1, logical reads 3023, physical reads 3, read-ahead reads 3018, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index Seek is 100% of Query Cost for test data, but it may result in a Table Scan depending on table size/structure

--A LIKE Clause with no wildcards
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col like '10000'
--Results in
--Table 'test'. Scan count 1, logical reads 3, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index Seek is 100% of Query Cost
GO

--an "=" clause = does Index Seek same as above
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col = '10000'
--Results in
--Table 'test'. Scan count 1, logical reads 3, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index Seek is 100% of Query Cost
GO

DROP TABLE test

Es kann auch einen vernachlässigbaren Unterschied bei der Erstellung des Abfrageplans geben, wenn "=" gegenüber "LIKE" verwendet wird.