Regex in Datenbanken: LIKE, REGEXP

Wer mit SQL-Datenbanken arbeitet, kommt früher oder später an Pattern-Suche: „alle Kunden deren Name mit S anfängt", „alle E-Mails von @gmail.com", „alle PLZ aus der 78er-Region". SQL hat zwei Werkzeuge dafür: das einfache LIKE mit Wildcards, und das mächtigere REGEXP mit echten regulären Ausdrücken.

Diese Lektion zeigt beide, mit allen wichtigen Unterschieden zwischen den DB-Systemen. Denn anders als die Sprachen Python oder JavaScript kocht jede Datenbank ihre eigene Suppe: MySQL, PostgreSQL, SQL Server und Oracle haben jeweils eigene Syntax.

1) LIKE: das einfache Werkzeug

LIKE ist SQL-Standard – funktioniert in jeder relationalen Datenbank gleich. Es kennt nur zwei Wildcard-Zeichen: % für „beliebig viele Zeichen" und _ für „genau ein Zeichen". Mit nur diesen zwei Zeichen lässt sich erstaunlich viel ausdrücken:

LIKE-Muster und ihre Bedeutung

'Anna'

Exakt „Anna". Wie ein normales =.

→ Anna ✓ · Anne ✗ · anna ✗

'Anna%'

Beginnt mit „Anna", danach beliebig viele Zeichen.

→ Anna ✓ · Anna_Mueller ✓ · annA ✗

'%@gmail.com'

Endet mit „@gmail.com" (alle Gmail-Adressen).

→ bob@gmail.com ✓ · gmail.com ✗

'%berlin%'

Enthält „berlin" irgendwo. Wie ein „contains".

→ Berlin ✗ (Case!) · in Berlin ✗ · berlinerin ✓

'_nna'

Genau 1 Zeichen + „nna" = 4 Zeichen total.

→ Anna ✓ · Hanna ✗ · Anne ✗

'M__er'

M, 2 beliebige Zeichen, er = 5 Zeichen.

→ Maier ✓ · Meier ✓ · Müller ✗

LIKE ist case-sensitivity-abhängig von der Datenbank-Konfiguration. MySQL ist standardmäßig case-insensitive (außer mit BINARY Collation). PostgreSQL ist case-sensitive. Für plattformunabhängige case-insensitive Suche: LOWER(spalte) LIKE LOWER('%muster%') oder PostgreSQL's ILIKE.

2) LIKE in Aktion

Praktische SQL-Queries mit LIKE:

LIKE-Beispiele

1-- Alle Namen die mit "S" beginnen
2SELECT * FROM users WHERE name LIKE 'S%';
3
4-- Alle E-Mails mit gmail-Domain
5SELECT * FROM users WHERE email LIKE '%@gmail.com';
6
7-- Telefonnummern aus dem 030er-Bereich (Berlin)
8SELECT * FROM contacts WHERE phone LIKE '030%';
9
10-- Negierung: NICHT-Gmail
11SELECT * FROM users WHERE email NOT LIKE '%@gmail.com';
12
13-- Mehrere LIKE-Bedingungen
14SELECT * FROM products 
15WHERE name LIKE '%Bio%' AND name LIKE '%Apfel%';

3) Escape-Charakter bei LIKE

Was wenn du wörtlich nach % oder _ suchen willst? Mit ESCAPE-Klausel:

LIKE mit Escape

1-- Suche nach wörtlichem Prozentzeichen
2SELECT * FROM products 
3WHERE description LIKE '%50\%%' ESCAPE '\\';
4-- Findet alle die "50%" enthalten
5
6-- Suche nach wörtlichem Underscore
7SELECT * FROM users WHERE username LIKE '%\_admin%' ESCAPE '\\';

4) Wo LIKE an Grenzen stößt

LIKE ist einfach – aber begrenzt. Sachen die mit LIKE NICHT gehen:

„Genau 5 Ziffern" – LIKE kann keine Ziffern von Buchstaben unterscheiden
„Beginnt mit Zahl" – kein Zeichenklassen-Konzept
„Optionaler Teil" – kein ?-Quantor
„Alternation A oder B" – kein |
„Genau 3 Wiederholungen" – kein {n}-Quantor

Für all das brauchst du REGEXP – die echten regulären Ausdrücke. Genau das ist Thema des nächsten Abschnitts.

5) REGEXP/RLIKE: echte Regex in SQL

Hier wird's interessant – und leider auch uneinheitlich je nach DB-System. Während LIKE überall gleich funktioniert, hat jede Datenbank ihre eigene REGEXP-Syntax. Übersicht:

REGEXP-Syntax pro Datenbank

MySQL

col REGEXP '^[0-9]+$'
col RLIKE '^[0-9]+$'

REGEXP = RLIKE (Alias). POSIX ERE.

MariaDB

col REGEXP '^[0-9]+$'

Wie MySQL, ab 10.0 mit PCRE-Engine.

PostgreSQL

col ~ '^[0-9]+$'
col ~* '^[0-9]+$'
col !~ '...' (Negation)

~ case-sensitive, ~* case-insensitive. Sehr mächtig.

SQL Server

LIKE mit erweiterten
[a-z], [^a-z]

Kein echter REGEXP! Nur erweiterte LIKE-Klassen.

Oracle

REGEXP_LIKE(col, '^[0-9]+$')
REGEXP_INSTR(col, ...)
REGEXP_REPLACE(col, ...)

Funktionsbasiert, sehr feature-reich.

SQLite

col REGEXP 'pattern'

Nur wenn REGEXP-Extension geladen ist!

SQL Server ist die große Ausnahme – kein echter REGEXP-Support. Stattdessen gibt's erweiterte LIKE-Klassen wie [a-z] direkt im LIKE-Pattern. Für vollständige Regex in SQL Server: CLR-Funktion oder externer Code. Mit SQL Server 2025 wurde aber endlich auch REGEXP_LIKE/etc. eingeführt.

6) REGEXP in MySQL/MariaDB

MySQL ist die wohl am häufigsten verwendete DB mit Regex-Support. Die Syntax ist einfach:

MySQL REGEXP-Beispiele

1-- Nur Einträge mit gültigem 5-stelligem PLZ
2SELECT * FROM addresses WHERE plz REGEXP '^[0-9]{5}$';
3
4-- Namen die mit A oder B anfangen
5SELECT * FROM users WHERE name REGEXP '^(A|B)';
6
7-- Telefonnummern im Format +49 30 xxxxxxx
8SELECT * FROM contacts 
9WHERE phone REGEXP '^\\+49 [0-9]+ [0-9]+$';
10
11-- Ungültige E-Mails finden
12SELECT * FROM users 
13WHERE email NOT REGEXP '^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$';
14
15-- Mehrere Patterns mit OR
16SELECT * FROM log_entries 
17WHERE message REGEXP 'ERROR|FATAL|WARN';

Wichtig: MySQL nutzt POSIX ERE – die meisten klassischen Regex-Features sind dabei, aber kein \d, \w, \s (das ist PCRE). Stattdessen [0-9], [a-zA-Z0-9_], [[:space:]]. Ab MariaDB 10.0+ wird PCRE genutzt – da geht auch \d.

7) REGEXP in PostgreSQL

PostgreSQL hat eine besonders elegante Syntax – mit Operatoren statt Keywords:

PostgreSQL Regex-Operatoren

1-- ~ case-sensitive Match
2SELECT * FROM users WHERE email ~ '@gmail\.com$';
3
4-- ~* case-insensitive
5SELECT * FROM users WHERE email ~* '@gmail\.com$';
6
7-- !~ negation
8SELECT * FROM users WHERE email !~ '@gmail\.com$';
9
10-- Funktionen: regexp_match, regexp_replace, regexp_split
11SELECT regexp_match(email, '(\w+)@(\w+\.\w+)') FROM users;
12-- Liefert Array mit Gruppen: ['anna', 'firma.de']
13
14-- Datum umformatieren
15UPDATE events SET date_str = regexp_replace(
16    date_str, '(\d{2})\.(\d{2})\.(\d{4})', '\3-\2-\1');

PostgreSQL's regexp_match gibt direkt ein Array mit den Capturing Groups zurück – perfekt für Extraktion. regexp_replace ist wie re.sub in Python. Mein persönlicher Favorit: das ~-Operator-Modell ist sehr kompakt und intuitiv.

8) Oracle: REGEXP_LIKE und Friends

Oracle macht alles mit Funktionen – sehr feature-reich, aber etwas länglich:

Oracle Regex-Funktionen

1-- Matchen
2SELECT * FROM users 
3WHERE REGEXP_LIKE(email, '@gmail\.com$');
4
5-- Substring extrahieren
6SELECT REGEXP_SUBSTR(text, '\d{4}') FROM messages;
7
8-- Position des Matches
9SELECT REGEXP_INSTR(text, '@') FROM users;
10
11-- Ersetzen
12SELECT REGEXP_REPLACE(text, '\d', 'X') FROM ...;
13
14-- Case-insensitive mit Flag
15SELECT * FROM users 
16WHERE REGEXP_LIKE(name, '^anna', 'i');

Oracle's vier Funktionen REGEXP_LIKE, REGEXP_SUBSTR, REGEXP_INSTR, REGEXP_REPLACE decken zusammen alles ab was du brauchst. Bei Oracle-DBs ist Regex sehr ausgereift.

9) Performance: das große Aber

⚠ Performance-Warnung

Regex-Operationen in der Datenbank umgehen meist Indizes. Bei Tabellen mit Millionen Zeilen kann das tödlich langsam sein – Full-Table-Scan ist nötig. Beispiel: Eine Query mit WHERE email REGEXP '@firma' auf einer Tabelle mit 10 Millionen Usern dauert Minuten, während WHERE email LIKE '%@firma.de' mit einem geeigneten Index oder email = 'anna@firma.de' Millisekunden. Mehr zu Performance in K46 L8 DB-Debugging.

Best Practices für Regex-Performance:

Anker am Anfang: '^abc' ist schneller als 'abc' – Engine kann früher abbrechen
LIKE wenn möglich: LIKE 'abc%' kann B-Tree-Index nutzen, REGEXP nicht
Spezifische Spalten: nicht SELECT *, nur was du brauchst
Pre-filter mit anderen Bedingungen: erst WHERE country = 'DE' AND plz REGEXP ... – Country-Filter reduziert die Daten enorm vor dem teuren Regex
Functional Indizes: PostgreSQL kann auf CREATE INDEX ON users (lower(email)) indizieren – dann ist lower(email) LIKE '...' indexed
Materialisierte Views für teure Regex-Suchen die wiederholt vorkommen
Validierung schon beim INSERT: lieber ein CHECK-Constraint mit Regex als jedes Mal SELECT mit Regex

10) CHECK-Constraints mit Regex

Eine elegante Anwendung von Regex in der DB: Datenintegrität direkt im Schema. Mit einem CHECK-Constraint sicherst du dass nie ungültige Daten in der DB landen:

CHECK-Constraint mit Regex (PostgreSQL)

1CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email TEXT NOT NULL,
  plz TEXT,
  CONSTRAINT valid_email 
      CHECK (email ~ '^[\w.+-]+@[\w.-]+\.\w{2,}$'),
  CONSTRAINT valid_plz
      CHECK (plz IS NULL OR plz ~ '^[0-9]{5}$')
9);

Damit kann nie eine ungültige E-Mail oder PLZ in die DB. INSERT-Versuche schlagen fehl. Datenintegrität auf Schema-Ebene – kein Bug im Anwendungscode kann ungültige Daten reinschreiben. Sehr empfehlenswert für kritische Felder.

11) NoSQL und Regex

Auch MongoDB und andere NoSQL-DBs unterstützen Regex:

MongoDB Regex

1// Alle User mit @gmail.com
2db.users.find({ email: { $regex: "@gmail\\.com$" } })
3
4// Mit Flag (case-insensitive)
5db.users.find({ email: { $regex: "@gmail", $options: "i" } })
6
7// Alternative Schreibweise:
8db.users.find({ email: /@gmail\.com$/i })

MongoDB nutzt PCRE – fast volle JavaScript-Regex-Syntax. Performance-Caveats wie bei SQL: ohne präfix-Anker kein Index, Full-Collection-Scan bei großen Datenmengen.

12) Praxis-Anwendungsfälle

Wo lohnt sich Regex in der DB wirklich?

Datenqualitätsprüfung: „Wie viele ungültige E-Mails haben wir in der DB?" – einmaliger Report
Data Cleaning: bestehende Daten mit REGEXP_REPLACE bereinigen (z.B. Telefonnummern vereinheitlichen)
Filter auf seltene Felder: kleine Tabellen, einmalige Analysen
CHECK-Constraints: Datenintegrität beim Schreiben
Computed Columns: extrahierte Werte (z.B. Top-Level-Domain aus E-Mail) für schnellere Suche

Wo NICHT:

Hot Path: Queries die hundertmal pro Sekunde laufen – lieber strukturieren
Große Tabellen ohne Vorfilter: Full-Scan kann Stunden dauern
Komplexe Validierung: lieber in Applikations-Code als in der DB

13) Vergleich: LIKE vs REGEXP

Kriterium	LIKE	REGEXP
SQL-Standard	✓ überall	✗ DB-spezifisch
Wildcards	% und _	Volle Regex-Syntax
Zeichenklassen	✗	✓ [a-z], \d, \w
Quantoren	✗	✓ +, *, {n,m}
Gruppen	✗	✓ (...)
Alternation	✗	✓ A\|B
Anker	implizit (^ am Anfang)	✓ ^ und $
Index-Nutzung	Mit Präfix-LIKE möglich	Selten möglich
Performance	Schnell	Langsam bei Volltable-Scan
Komplexität	Sehr einfach	Volle Regex-Macht

Faustregel: LIKE wenn möglich, REGEXP wenn nötig. Bei einfachen Mustern wie „beginnt mit", „endet mit", „enthält": LIKE. Bei komplexen Mustern mit Zeichenklassen, Quantoren oder Alternation: REGEXP.

Zusammenfassung

SQL hat zwei Pattern-Werkzeuge: LIKE (Standard, mit Wildcards % und _, einfach + indexfähig) und REGEXP (DB-spezifisch, mächtig, meist ohne Index). Syntax pro DB: MySQL REGEXP/RLIKE, PostgreSQL ~/~*/!~, Oracle REGEXP_LIKE(), SQL Server ältere Versionen ohne echten REGEXP. Performance: Regex umgeht meist Indizes – bei großen Tabellen langsam. Vorfilter mit anderen Bedingungen nutzen. CHECK-Constraints mit Regex sichern Datenintegrität direkt im Schema. Faustregel: LIKE wenn möglich, REGEXP wenn nötig.