MySQL 인덱스
MySQL은 첫 번째 열부터 전체 테이블에 걸쳐서 연관된 열을 검색하기 때문에 테이블이 크면 클수록 검색속도가 엄청나게 느려진다.
SQL은 테이블에 있는 행(record)를 접근하는 방법은 순차적 접근(sequential access) 방법이고, 다른 하나는 직접 접근(direct access) 이다.
테이블이 많은 행을 가지고 있을 때 오직 하나의 행만 찾는다면 많은 시간을 소비하고 비효율적이다.
MySQL 전문(full-text) 검색은 작은 데이터 집합에서는 빠르지만 데이터의 크기가 커지면 성능이 나빠진다.
레코드가 100만개 있는 경우나 Index 된 텍스트의 크기가 기가바이트 단위인 경우 Query 수행 시간은 1초 ~ 10분 사이를 왔다갔다 하게 되므로 고성능 웹 응용 프로그램에서는 사용할 수가 없다.
MySQL 은 적절한 스키마와 최적화된 Query가 있고, WHERE절에 너무 많은 칼럼이 들어 있지 않은 한 잘 동작한다. 하지만 칼럼수가 늘어나고, 가능한 모든 경우에 대한 검색 기능을 지원하려고 한다면 필요한 Index 수가 기하급수적으로 늘어난다.
Index 를 추가하더라도 해당 칼럼이 절반정도가 선택되는 경우라면 Index 가 별로 도움이 안되어 Full Scan 을 사용한다.
MySQL 은 Index Scan 을 사용할지 Full Table Scan을 사용할지를 자동적으로 결정한다.
MySQL 은 Index 를 사용해서 매치되는 행을 찾고, 디스크에 무작위 순서로 접근하면서 레코드들을 하나하나 읽어낸 뒤 Sort 버퍼에 집어넣는다. 그런 다음 파일 정렬을 통해 값을 정렬하고, 정렬된 값들 중 대부분을 버리게 된다. 이 과정에서 LIMIT 절에 상관없이 전체 결과를 임시로 저장해서 처리한다. 만약 결과 set 이 Sort 버퍼에 다 들어갈 수 없다면 결과 set 은 디스크에 저장되어야 하므로 디스크 I/O까지도 많이 발생시키게 된다.
'SQL' 카테고리의 다른 글
| phpMyAdmin 을 이용한 테이블 등록 (0) | 2014.12.01 |
|---|---|
| MySQL 통계 Group by (0) | 2014.11.30 |
| MySQL 테이블간 데이터 복사(구조가 다른 경우 포함) (0) | 2014.11.12 |
| [보안] MySQL의 root 패스워드 분실시 대처법 (0) | 2014.11.09 |
| [SQL] SELECT DISTINCT 구문 (0) | 2014.08.30 |
Link2Me