DB

왜 우리는 B+tree만 쓰고 있을까 feat. B-tree, B*tree와의 차이이론적으로 더 좋다는 B*tree는 왜 아무도 안 쓰는가 WHY? core question 이전 글에서 B+tree의 한계를 봤다. LIKE '%keyword%'처럼 앞에 와일드카드가 붙으면 시작점을 잡을 수 없었다. 그런데도 왜 대부분의 RDBMS는 여전히 B+tree를 기본 인덱스로 사용할까? 더 나아가, 왜 이름만 보면 더 좋아 보이는 B*tree는 실무 표준이 되지 못했을까? Why B+tree? │ ┌─────────┼─────────┐ │ │ │ I/O Range Con..

검색은 빨라야 한다, 그런데 쓰기도 빨라야 한다면? (feat. PostgreSQL GiST)GIN이 모든 답은 아니다. pg_trgm에서 GiST를 선택해야 하는 순간들이전 글에서는 MySQL에서 LIKE '%keyword%'가 왜 느린지, 그리고 PostgreSQL에서는 pg_trgm + GIN 조합으로 이 문제를 어떻게 더 깔끔하게 해결할 수 있는지 정리했다.흐름을 다시 요약하면 이렇다.1편: MySQL B+Tree index는 leading wildcard가 붙은 LIKE '%keyword%' 검색에서 seek point를 잡지 못한다.2편: PostgreSQL은 pg_trgm + GIN으로 LIKE 문법을 유지하면서도 substring search를 인덱스로 가속할 수 있다.CORE이번 글의 핵..

제 검색 속도는 안녕합니다 (feat. PostgreSQL GIN + pg_trgm)MySQL FULLTEXT와는 무엇이 다른가이전 글에서 MySQL의 LIKE '%WildCard%' 문제와, FULLTEXT index + ngram parser로 우회하는 방법을 다뤘다.2026.05.13 - [DB/MySQL] - 당신의 검색 속도는 안녕하십니까?(feat. MySQL Index)핵심은 이거였다. B+Tree index는 leading character 기준으로 정렬된 자료구조이기 때문에, leading wildcard가 붙은 substring search는 sargable하지 않다. 그래서 인덱스가 있어도 full index scan으로 떨어진다.MySQL에서는 FULLTEXT index에 ngram..

당신의 검색 속도가 느린 이유(feat. Index는 만능 열쇠가 아니다!)MySQL B+Tree Index와 FULLTEXT Index의 차이Index는 흔히 "검색 성능 문제의 만능 열쇠"처럼 여겨진다. 쿼리가 느리면 일단 인덱스부터 걸어보고, EXPLAIN에 인덱스 이름이 잡히면 안심하는 경우가 많다. 그런데 인덱스를 만들어도 쿼리는 여전히 느릴 수 있다. 인덱스를 탔다는 사실과 빠르게 동작한다는 사실은 별개의 문제이기 때문이다.회원 검색 API를 개발하다 보면 이런 상황을 마주할 수 있다.SELECT id, name, phoneFROM memberWHERE name LIKE '%윤혁%'LIMIT 20;회원 이름으로 검색하는 단순한 쿼리다. member 테이블에는 약 500만 건의 row가 있었고,..