LIKE vs. LEFT: Welche Methode gewinnt beim Präfixvergleich?

Im Alltag eines SQL-Entwicklers oder DBAs begegnet einem immer wieder die gleiche Frage: Soll ich einen Präfixvergleich mit LIKE 'abc%' oder mit LEFT(Spalte, 3) = 'abc' durchführen? Beide Varianten liefern auf den ersten Blick das gleiche Ergebnis – alle Zeilen, deren Spalte mit „abc“ beginnt. Doch unter der Haube verhalten sie sich völlig unterschiedlich. In diesem Artikel schauen wir uns an, welche Variante schneller ist, warum und welchen Einfluss Indizes haben.

📌 Das Beispielszenario

Stellen Sie sich eine Tabelle Customers mit einer Spalte CustomerCode vor, die einen Buchstaben‑Präfix hat, z.B. "ABC-1001", "ABC-1002", "ABD-2001". Sie möchten alle Kunden finden, deren Code mit 'ABC' beginnt.

-- Variante 1: LIKE mit Wildcard 
SELECT * FROM Customers WHERE CustomerCode LIKE 'ABC%'; 
 
-- Variante 2: LEFT-Funktion 
SELECT * FROM Customers WHERE LEFT(CustomerCode, 3) = 'ABC';

⚡ Performance‑Vergleich (mit und ohne Index)

Die entscheidende Frage: Kann der SQL Server einen Index nutzen? Ein Index nach CustomerCode sortiert die Werte lexikografisch. Ein Präfixvergleich sollte den Index optimal ausnutzen können – wenn der Optimierer die Operation als sargable (Search ARGument ABLE) erkennt.

🔍 LIKE 'abc%' – sargable (gut)

Der Operator LIKE mit einem konstanten Präfix und einem abschließenden Platzhalter % ist sargable. SQL Server wandelt dies intern in einen Index Seek um, sofern ein passender Index existiert. Die Abfrage sucht dann nach den ersten Werten, die mit "ABC" beginnen, und liest den Index nur in diesem Bereich.

-- Führt zu einem Index Seek (schnell) 
SELECT CustomerCode FROM Customers WHERE CustomerCode LIKE 'ABC%';

🔍 LEFT(Spalte, 3) = 'abc' – nicht sargable (schlecht)

Bei LEFT(CustomerCode, 3) = 'ABC' muss SQL Server zunächst für jede Zeile die LEFT-Funktion auswerten. Dieser Ausdruck ist nicht sargable, weil der Index auf dem ursprünglichen Wert basiert – das Ergebnis der Funktion ist eine berechnete Spalte. Das Ergebnis: Ein Table Scan (oder Index Scan), der die gesamte Tabelle liest.

📊 Vergleichstabelle (100.000 Zeilen, Index auf CustomerCode)

(Messungen auf SQL Server 2022 mit repräsentativen Daten – Ihre tatsächlichen Werte können variieren, aber der Unterschied ist immer signifikant.)

🎯 Ausnahmen und Randfälle

Es gibt Situationen, in denen LEFT dennoch akzeptabel sein kann:

• Sehr kleine Tabellen (wenige hundert Zeilen) – der Scan ist irrelevant.
• Die Spalte ist nicht indiziert – dann müssen beide Varianten scannen, aber LIKE ist oft trotzdem etwas günstiger, weil keine Funktionsauswertung pro Zeile nötig ist.
• Indizierte Sichten oder berechnete Spalten – wenn Sie eine persistente berechnete Spalte für LEFT(Spalte,3) anlegen und indizieren, dann wird auch diese Version sargable. Aber das ist Overkill für einfache Präfixabfragen.

🧪 Bonus: Was ist mit SUBSTRING(Spalte, 1, 3) = 'abc'?

SUBSTRING verhält sich genauso wie LEFT – es ist eine Funktion auf der Spalte und blockiert die Indexnutzung. Gleiches gilt für CHARINDEX oder PATINDEX. Einzige Ausnahme: LIKE 'abc%' (und auch LIKE '[A-Z]%' mit Bereich) ist sargable, solange das Muster mit einem konstanten Präfix beginnt.

✅ Best Practice für Präfixvergleiche

• Immer LIKE 'konstanterPräfix%' verwenden, wenn Sie einen Index nutzen möchten.
• KEINE Funktionen auf der zu filternden Spalte anwenden – sonst verabschiedet sich der Index.
• Prüfen Sie Ihre Abfragen mit dem tatsächlichen Ausführungsplan (Ctrl+L oder Ctrl+M in SSMS).

-- Empfohlene Variante 
SELECT * FROM dbo.Customers 
WHERE CustomerCode LIKE 'ABC%'; 
 
-- Falls Sie case‑insensitive Vergleiche brauchen: Kollation der Spalte prüfen 
-- Oder explizit: WHERE CustomerCode LIKE 'abc%' COLLATE Latin1_General_CI_AI;

📈 Kleine Optimierung: Covering Index

Wenn Sie oft nach CustomerCode filtern und zusätzliche Spalten benötigen, erstellen Sie einen abdeckenden Index:

CREATE INDEX IX_Customers_Code ON dbo.Customers (CustomerCode) INCLUDE (Name, City);

Dann liefert bereits der Index Seek alle benötigten Daten ohne Zugriff auf die Basistabelle (Key Lookup).

🧰 PowerShell & sqmSQLTool: Performance‑Analyse automatisieren

Mit unserem sqmSQLTool können Sie solche Abfragen auf Ihrer gesamten SQL Landschaft analysieren. Das Cmdlet Get-sqmQueryPerformance zeigt Ihnen automatisch Abfragen an, die nicht sargable Ausdrücke wie LEFT(column, ...) oder SUBSTRING enthalten – und gibt konkrete Handlungsempfehlungen.

# Analyse der Top-10 teuersten Abfragen mit Funktionsaufrufen 
Get-sqmQueryPerformance -SqlInstance "PRODSQL01" -NonSargableOnly -TopN 10 
 
# Ausgabe als HTML-Report 
Invoke-sqmPerformanceReport -SqlInstance "PRODSQL01" -OutputPath "C:\Reports"

So behalten Sie auch in großen Umgebungen den Überblick, ohne jede Abfrage manuell prüfen zu müssen.

📝 Zusammenfassung

• LIKE 'abc%' ✅ – indexfreundlich, schnell, sargable.
• LEFT(column,3) = 'abc' ❌ – nicht sargable, vermeiden auf großen Tabellen.
• Im Zweifel: Ausführungsplan prüfen – ein Scan ist ein Alarmsignal.
• Nutzen Sie Tools wie sqmSQLTool, um solche Anti-Patterns automatisiert zu erkennen.

Die Regel ist simpel: Wenden Sie keine Funktionen auf der gefilterten Spalte an. Wenn Sie das beherzigen, werden Ihre Abfragen skalieren – und Ihre Datenbank wird es Ihnen danken.