Gibt es bei der Verwendung von SQL Vorteile bei der Verwendung =in einer WHEREKlausel anstelle von LIKE?

Ohne spezielle Operatoren LIKEund =gleich, oder?

Verschiedene Operatoren

LIKEund =sind verschiedene Operatoren. Die meisten Antworten konzentrieren sich auf die Wildcard-Unterstützung, die nicht der einzige Unterschied zwischen diesen Operatoren ist!

=ist ein Vergleichsoperator, der mit Zahlen und Zeichenfolgen arbeitet. Beim Vergleichen von Zeichenfolgen vergleicht der Vergleichsoperator ganze Zeichenfolgen .

LIKEist ein Zeichenfolgenoperator, der Zeichen für Zeichen vergleicht .

Um die Sache zu verkomplizieren, verwenden beide Operatoren eine Kollatierung, die wichtige Auswirkungen auf das Vergleichsergebnis haben kann.

Motivierendes Beispiel

Lassen Sie uns zunächst ein Beispiel identifizieren, bei dem diese Operatoren offensichtlich unterschiedliche Ergebnisse liefern. Lassen Sie mich aus dem MySQL-Handbuch zitieren:

Gemäß dem SQL-Standard führt LIKE den Abgleich auf Zeichenbasis durch, sodass Ergebnisse erzielt werden können, die sich vom Vergleichsoperator = unterscheiden:

mysql> SELECT 'ä' LIKE 'ae' COLLATE latin1_german2_ci;
+-----------------------------------------+
| 'ä' LIKE 'ae' COLLATE latin1_german2_ci |
+-----------------------------------------+
|                                       0 |
+-----------------------------------------+
mysql> SELECT 'ä' = 'ae' COLLATE latin1_german2_ci;
+--------------------------------------+
| 'ä' = 'ae' COLLATE latin1_german2_ci |
+--------------------------------------+
|                                    1 |
+--------------------------------------+

Bitte beachten Sie, dass diese Seite des MySQL-Handbuchs als String-Vergleichsfunktionen bezeichnet wird und =nicht behandelt wird, was dies impliziert= es sich nicht ausschließlich um eine String-Vergleichsfunktion handelt.

Wie funktioniert das =?

Der SQL-Standard § 8.2 beschreibt, wie =Zeichenfolgen verglichen werden:

Der Vergleich zweier Zeichenketten wird wie folgt bestimmt:

a) Wenn die Länge in Zeichen von X nicht gleich der Länge in Zeichen von Y ist, wird die kürzere Zeichenfolge zu Vergleichszwecken effektiv durch eine Kopie von sich selbst ersetzt, die auf die Länge der längeren Zeichenfolge erweitert wurde durch Verkettung rechts von einem oder mehreren Pad-Zeichen, wobei das Pad-Zeichen basierend auf CS ausgewählt wird. Wenn CS das NO PAD-Attribut hat, ist das Pad-Zeichen ein implementierungsabhängiges Zeichen, das sich von jedem Zeichen im Zeichensatz von X und Y unterscheidet, das weniger als jede Zeichenfolge unter CS sortiert. Andernfalls ist das Pad-Zeichen a.

b) Das Ergebnis des Vergleichs von X und Y ergibt sich aus der Sortierfolge CS.

c) Abhängig von der Sortierfolge können zwei Zeichenfolgen als gleich verglichen werden, auch wenn sie unterschiedlich lang sind oder unterschiedliche Zeichenfolgen enthalten. Wenn die Operationen MAX, MIN, DISTINCT, Verweise auf eine Gruppierungsspalte und die Operatoren UNION, EXCEPT und INTERSECT auf Zeichenfolgen verweisen, ist der spezifische Wert, den diese Operationen aus einem Satz solcher gleichen Werte auswählen, implementierungsabhängig.

(Betonung hinzugefügt.)

Was bedeutet das? Dies bedeutet, dass der =Operator beim Vergleichen von Zeichenfolgen nur ein dünner Wrapper um die aktuelle Sortierung ist. Eine Kollatierung ist eine Bibliothek, die verschiedene Regeln zum Vergleichen von Zeichenfolgen enthält. Hier ist ein Beispiel für eine binäre Zusammenstellung von MySQL :

static int my_strnncoll_binary(const CHARSET_INFO *cs __attribute__((unused)),
                               const uchar *s, size_t slen,
                               const uchar *t, size_t tlen,
                               my_bool t_is_prefix)
{
  size_t len= MY_MIN(slen,tlen);
  int cmp= memcmp(s,t,len);
  return cmp ? cmp : (int)((t_is_prefix ? len : slen) - tlen);
}

Diese bestimmte Kollatierung vergleicht Byte für Byte (weshalb sie "binär" genannt wird - sie gibt Zeichenfolgen keine besondere Bedeutung). Andere Kollatierungen bieten möglicherweise erweiterte Vergleiche.

Hier ist beispielsweise eine UTF-8-Kollatierung , die Vergleiche ohne Berücksichtigung der Groß- und Kleinschreibung unterstützt. Der Code ist zu lang, um ihn hier einzufügen, aber gehen Sie zu diesem Link und lesen Sie den Text von my_strnncollsp_utf8mb4(). Diese Sortierung kann mehrere Bytes gleichzeitig verarbeiten und verschiedene Transformationen anwenden (z. B. Vergleich ohne Berücksichtigung der Groß- und Kleinschreibung). Der =Operator ist vollständig von den Launen der Kollatierung abstrahiert.

Wie funktioniert das LIKE?

Der SQL-Standard § 8.5 beschreibt, wie LIKEZeichenfolgen verglichen werden:

Das <Prädikat>

M LIKE P

ist wahr, wenn es eine Aufteilung von M in Teilzeichenfolgen gibt, so dass:

i) Eine Teilzeichenfolge von M ist eine Folge von 0 oder mehr zusammenhängenden <Zeichenrepräsentationen> s von M, und jede <Zeichenrepräsentation> von M ist Teil genau einer Teilzeichenfolge.

ii) Wenn der i-te Teilstringspezifizierer von P ein beliebiger Zeichenspezifizierer ist, ist der i-te Teilstringspezifizierer von M eine einzelne <Zeichenrepräsentation>.

iii) Wenn der i-te Teilstringspezifizierer von P ein beliebiger Zeichenkettenspezifizierer ist, dann ist der i-te Teilstringspezifizierer von M eine beliebige Folge von 0 oder mehr <Zeichendarstellung> s.

iv) Wenn der i-te Teilzeichenfolgenspezifizierer von P weder ein beliebiger Zeichenspezifizierer noch ein beliebiger Zeichenfolgenspezifizierer ist, dann ist der i-te Teilzeichenfolgenspezifizierer von M gleich diesem Teilzeichenfolgenspezifizierer gemäß der Sortierfolge des <ähnlichen Prädikats> ohne das Anhängen von <Leerzeichen> an M und hat die gleiche Länge wie dieser Teilstring-Bezeichner.

v) Die Anzahl der Teilzeichenfolgen von M entspricht der Anzahl der Teilzeichenfolgenspezifizierer von P.

(Betonung hinzugefügt.)

Das ist ziemlich wortreich, also lasst es uns zusammenfassen. Artikel II und III beziehen sich auf die Platzhalter _und %, respectively. Wenn Pkeine Platzhalter enthalten sind, gilt nur Punkt iv. Dies ist der Fall von Interesse, das vom OP gestellt wird.

In diesem Fall wird jeder "Teilstring" (einzelne Zeichen) mit Mjedem Teilstring unter PVerwendung der aktuellen Sortierung verglichen .

Schlussfolgerungen

Die Quintessenz ist, dass beim Vergleichen von Zeichenfolgen =die gesamte Zeichenfolge verglichen wird, während jeweils LIKEein Zeichen verglichen wird. Beide Vergleiche verwenden die aktuelle Sortierung. Dieser Unterschied führt in einigen Fällen zu unterschiedlichen Ergebnissen, wie das erste Beispiel in diesem Beitrag zeigt.

Welches solltest du verwenden? Niemand kann Ihnen das sagen - Sie müssen diejenige verwenden, die für Ihren Anwendungsfall richtig ist. Optimieren Sie nicht vorzeitig, indem Sie die Vergleichsoperatoren wechseln.

Der Operator equals (=) ist ein "Vergleichsoperator, der zwei Werte auf Gleichheit vergleicht". Mit anderen Worten, in einer SQL-Anweisung wird true nur zurückgegeben, wenn beide Seiten der Gleichung gleich sind. Beispielsweise:

SELECT * FROM Store WHERE Quantity = 200;

Der LIKE-Operator "implementiert einen Mustervergleichsvergleich", der versucht, "einen Zeichenfolgenwert mit einer Musterzeichenfolge abzugleichen, die Platzhalterzeichen enthält". Beispielsweise:

SELECT * FROM Employees WHERE Name LIKE 'Chris%';

LIKE wird im Allgemeinen nur mit Strings verwendet und Equals (glaube ich) sind schneller. Der Operator equals behandelt Platzhalterzeichen als Literalzeichen. Der Unterschied in den zurückgegebenen Ergebnissen ist wie folgt:

SELECT * FROM Employees WHERE Name = 'Chris';

Und

SELECT * FROM Employees WHERE Name LIKE 'Chris';

Würde das gleiche Ergebnis zurückgeben, obwohl die Verwendung von LIKE im Allgemeinen länger dauern würde, da es sich um eine Musterübereinstimmung handelt. Jedoch,

SELECT * FROM Employees WHERE Name = 'Chris%';

Und

SELECT * FROM Employees WHERE Name LIKE 'Chris%';

Würde unterschiedliche Ergebnisse zurückgeben, wobei die Verwendung von "=" nur zu Ergebnissen führt, wobei "Chris%" zurückgegeben wird und der LIKE-Operator alles zurückgibt, was mit "Chris" beginnt.

Hoffentlich hilft das. Einige gute Infos finden Sie hier .

Dies ist ein Kopieren / Einfügen einer anderen Antwort von mir auf die Frage SQL 'wie' vs '=' Leistung :

Ein persönliches Beispiel mit MySQL 5.5: Ich hatte eine innere Verknüpfung zwischen zwei Tabellen, einer von 3 Millionen Zeilen und einer von 10.000 Zeilen.

Bei Verwendung eines Like für einen Index wie unten (keine Platzhalter) dauerte es ungefähr 30 Sekunden:

where login like '12345678'

mit 'erklären' bekomme ich:

Bei Verwendung eines '=' für dieselbe Abfrage dauerte es ungefähr 0,1 Sekunden:

where login ='12345678'

Mit 'EXPLAIN' bekomme ich:

Wie Sie sehen können, hat die likeIndexsuche vollständig abgebrochen, sodass die Abfrage 300-mal länger dauerte.

LIKEund =sind anders. LIKEist das, was Sie in einer Suchabfrage verwenden würden. Es erlaubt auch Platzhalter wie _(einfacher Platzhalter für Zeichen) und %(Platzhalter für mehrere Zeichen).

= sollte verwendet werden, wenn Sie genaue Übereinstimmungen wünschen und es wird schneller sein.

Diese Seite erklärt LIKE

Ein Unterschied - abgesehen von der Möglichkeit, Platzhalter mit LIKE zu verwenden - besteht in nachgestellten Leerzeichen: Der Operator = ignoriert nachfolgende Leerzeichen, LIKE jedoch nicht.

Hängt vom Datenbanksystem ab.

Im Allgemeinen ohne Sonderzeichen sind yes, = und LIKE gleich.

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

Zum Beispiel wird bei MySQL-Vergleichen mit = on Strings standardmäßig immer zwischen Groß- und Kleinschreibung unterschieden, sodass LIKE ohne Sonderzeichen dasselbe ist. Bei einigen anderen RDBMS wird bei LIKE nicht zwischen Groß- und Kleinschreibung unterschieden, bei = nicht.

In diesem Beispiel nehmen wir an, dass varcharcol ''keine leere Zelle für diese Spalte enthält und keine hat

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

Die erste führt zu einer Ausgabe von 0 Zeilen, während die zweite die gesamte Liste anzeigt. = ist ein streng übereinstimmender Fall, während like wie ein Filter wirkt. Wenn der Filter keine Kriterien hat, sind alle Daten gültig.

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

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

Die Verwendung von "=" ist in diesem Fall etwas schneller (Suche nach einer genauen Ü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 Verwenden Sie dann "Abfrage" / "Tatsächlichen Ausführungsplan einschließen".

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% gegenüber 50% aufgeteilt, aber der Ausführungsplan "=" hat geringere "geschätzte Teilbaumkosten" (wird angezeigt, wenn Sie mit der Maus über das Feld "SELECT" ganz links fahren) - aber auch hier ist es wirklich so kein großer Unterschied.

Wenn Sie jedoch mit Platzhaltern in Ihrem LIKE-Ausdruck suchen, nimmt die Suchleistung ab. Die Suche "LIKE Mill%" kann immer noch recht schnell sein - SQL Server kann einen Index für diese Spalte verwenden, falls vorhanden. Die Suche nach "LIKE% expression%" ist schrecklich langsam, da SQL Server diese Suche nur durch einen vollständigen Tabellenscan erfüllen kann. Also sei vorsichtig mit deinen LIKE's!

Marc

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

Dies erleichtert dem Programmierer das Leben, da nicht alle speziellen Platzhalterzeichen, die in der LIKE-Klausel enthalten sein könnten, entkommen müssen und nicht das beabsichtigte Ergebnis erzielt werden. Immerhin ist = das 99% -Anwendungsszenario, es wäre ein Schmerz, jedes Mal entkommen zu müssen.

rollt die Augen in den 90ern

Ich vermute auch, dass es etwas langsamer ist, aber ich bezweifle, dass es wichtig ist, wenn das Muster keine Platzhalter enthält.

Um die ursprüngliche Frage zur Leistung zu beantworten, kommt es auf die Indexnutzung an . Wenn ein einfacher Tabellenscan durchgeführt wird, sind "LIKE" und "=" identisch . Wenn es sich um Indizes handelt, hängt dies davon ab, wie die LIKE-Klausel gebildet wird. Wo befinden sich die Platzhalter?

Folgendes berücksichtigen:

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

Bei Verwendung von "=" vs "LIKE" kann es auch zu vernachlässigbaren Unterschieden bei der Erstellung des Abfrageplans kommen.

Neben den Platzhaltern hängt der Unterschied zwischen =UND LIKEsowohl von der Art des SQL-Servers als auch vom Spaltentyp ab.

Nehmen Sie dieses Beispiel:

CREATE TABLE testtable (
  varchar_name VARCHAR(10),
  char_name CHAR(10),
  val INTEGER
);

INSERT INTO testtable(varchar_name, char_name, val)
    VALUES ('A', 'A', 10), ('B', 'B', 20);

SELECT 'VarChar Eq Without Space', val FROM testtable WHERE varchar_name='A'
UNION ALL
SELECT 'VarChar Eq With Space', val FROM testtable WHERE varchar_name='A '
UNION ALL
SELECT 'VarChar Like Without Space', val FROM testtable WHERE varchar_name LIKE 'A'
UNION ALL
SELECT 'VarChar Like Space', val FROM testtable WHERE varchar_name LIKE 'A '
UNION ALL
SELECT 'Char Eq Without Space', val FROM testtable WHERE char_name='A'
UNION ALL
SELECT 'Char Eq With Space', val FROM testtable WHERE char_name='A '
UNION ALL
SELECT 'Char Like Without Space', val FROM testtable WHERE char_name LIKE 'A'
UNION ALL
SELECT 'Char Like With Space', val FROM testtable WHERE char_name LIKE 'A '

• Bei Verwendung von MS SQL Server 2012 werden die nachgestellten Leerzeichen im Vergleich ignoriert, außer LIKEwenn der Spaltentyp lautet VARCHAR.

• Mit MySQL 5.5 werden die hinteren Räume außer Acht gelassen werden =, aber nicht für LIKE, beide mit CHARund VARCHAR.

• Bei Verwendung von PostgreSQL 9.1 sind Leerzeichen sowohl für =als auch für LIKEusing von Bedeutung VARCHAR, jedoch nicht für CHAR(siehe Dokumentation) ).

  Das Verhalten mit LIKEunterscheidet sich auch mitCHAR .

  Die Verwendung der gleichen Daten wie oben und die Verwendung eines expliziten CASTSpaltennamens machen ebenfalls einen Unterschied :

  SELECT 'CAST none', val FROM testtable WHERE char_name LIKE 'A'
  UNION ALL
  SELECT 'CAST both', val FROM testtable WHERE
      CAST(char_name AS CHAR) LIKE CAST('A' AS CHAR)
  UNION ALL
  SELECT 'CAST col', val FROM testtable WHERE CAST(char_name AS CHAR) LIKE 'A'
  UNION ALL
  SELECT 'CAST value', val FROM testtable WHERE char_name LIKE CAST('A' AS CHAR)

  Dies gibt nur Zeilen für "CAST sowohl" als auch "CAST col" zurück.

Das Schlüsselwort LIKE ist zweifellos mit einem "Leistungspreisschild" versehen. Wenn Sie jedoch ein Eingabefeld haben, das möglicherweise Platzhalterzeichen enthalten kann, die in Ihrer Abfrage verwendet werden sollen, würde ich die Verwendung von LIKE nur empfehlen, wenn die Eingabe einen der Platzhalter enthält. Verwenden Sie andernfalls den Standard, der dem Vergleich entspricht.

Freundliche Grüße...

Es kommt wirklich darauf an, was die Abfrage tun soll. Wenn Sie eine genaue Übereinstimmung meinen, verwenden Sie =. Wenn Sie ein unschärferes Spiel meinen, verwenden Sie LIKE. Zu sagen, was Sie meinen, ist normalerweise eine gute Richtlinie mit Code.

In Oracle gibt ein "Gefällt mir" ohne Platzhalter das gleiche Ergebnis wie ein "Gleiches" zurück, erfordert jedoch möglicherweise eine zusätzliche Verarbeitung. Laut Tom Kyte wird Oracle ein " Gefällt mir" ohne Platzhalter als "Gleich" behandeln, wenn Literale verwendet werden, nicht jedoch, wenn Bindungsvariablen verwendet werden.

=und LIKEist nicht dasselbe;

1. = stimmt mit der genauen Zeichenfolge überein
2. LIKE stimmt mit einer Zeichenfolge überein, die Platzhalter enthalten kann (%)