SQL, Unicode, 성능 노트

DB 의 정규식

대부분 현대 DB 가 정규식 매칭 지원:

PostgreSQL: ~ (case-sensitive), ~* (case-insensitive), !~/!~* (negated). POSIX ERE 사용.
MySQL/MariaDB: REGEXP 또는 RLIKE. 제한된 POSIX ERE.
SQLite: REGEXP 가 extension 로딩 또는 user-defined function 필요.
Snowflake: RLIKE, REGEXP_LIKE, 거기 REGEXP_SUBSTR, REGEXP_REPLACE.

DB 가로질러 흔한 헬퍼 함수: regexp_replace, regexp_substr, regexp_count.

정규식의 Unicode — 함정

크로스 언어 정규식 버그의 가장 큰 출처가 Unicode 처리:

Python re: \d, \w, \s 가 기본 Unicode-aware. re.ASCII 로 되돌림.
JavaScript: 적절한 Unicode 위해 /u 플래그 필요. \w 가 /u 있어도 ASCII-only — Unicode 문자엔 \p{L}.
RE2/Go: 기본 ASCII-only. Unicode 카테고리엔 \p{Nd}, \pL.
PCRE: 기본 ASCII; Unicode-aware 위해 (*UCP) 또는 /u.

본인 데이터가 Unicode 면 항상 실제 Unicode 입력에 정규식 테스트. ASCII 테스트가 이 버그 안 드러냄.

성능 — universal 룰

재사용 패턴 컴파일. 여러 매칭에 amortize 된 일회성 비용.
가능하면 anchor. ^pattern 가 엔진이 모든 위치 시도 막음.
Alternation 보다 character class. [abc] 가 a|b|c 이김.
Catastrophic backtracking 회피. (a+)+, (a|a)+, (.*)* 같은 패턴이 지수적. 트랙 8 이 ReDoS 다룸.
거대한 파일: 스트림, 로드 X. 대부분 정규식 API 가 iterator 또는 generator 작동.

요점

정규식이 dialect-aware. 같은 아이디어, 환경마다 약간 다른 표면. 트랙 1 멘탈 모델 — "모양 언어, 엔진이 입력 걷기" — 가 어디든 carry. 80% portable subset 이 본인 집; 나머지가 필요할 때 dialect 룩업.

Code

DB 정규식 예시·sql

-- PostgreSQL
SELECT * FROM users WHERE email ~ '^[\w.+-]+@example\.com$';
SELECT regexp_replace(name, '\s+', '_', 'g') FROM users;

-- MySQL
SELECT * FROM logs WHERE message REGEXP 'ERROR|WARN';
SELECT REGEXP_SUBSTR(url, '/api/v[0-9]+/[^/]+') FROM requests;

-- Snowflake
SELECT * FROM events WHERE payload RLIKE '"event_type":"(login|signup)"';
SELECT REGEXP_REPLACE(text, '[^\x20-\x7E]', '', 1, 0, 'g') FROM messages;

-- SQLite (REGEXP 함수 로드 필요)
SELECT * FROM logs WHERE level REGEXP '^(ERROR|FATAL)$';

SQL, Unicode, 성능 노트

DB 의 정규식

정규식의 Unicode — 함정

성능 — universal 룰

요점

Code

External links

Exercise

Progress

댓글 0