MySQL SELECT 성능은 왜 InnoDB가 MyISAM보다 빠를까? – 구조적 이유
MyISAM은 SELECT가 빠르고 InnoDB는 느리다
그런 경우도 있고 아닌 경우도 있기 때문에 어떤 용도로 사용하느냐에 따라서 다를 수 있습니다.
그리고 처음 데이터 넣은 다음 select만 90% 이상이고 테이블 사용이 업데이트나 인서트는 적은 경우인지 불특정 다수에게 서비스 하기 때문에 불특정한 row를 가져와서 보여줘야 하는것인지에 다를 수 있는 것입니다.
● 가장 큰 차이: 데이터와 인덱스 구조
→ MyISAM
- 데이터 파일(.MYD) 과 인덱스 파일(.MYI) 이 분리됨
- 인덱스 → 데이터 파일을 다시 읽는 구조
- 동작흐름: PK 인덱스 탐색 (.MYI) -> 데이터 위치 확인 -> 데이터 파일(.MYD) 접근
→ InnoDB
- 클러스터드 인덱스 구조
- PK 인덱스 자체가 데이터
- 동작흐름: InnoDB 동작 흐름 -> PK 인덱스 탐색 -> 바로 데이터 반환
PK 조회가 잦은 서비스에서는 InnoDB가 구조적으로 유리합니다.
● 실제 서비스 환경에서는 동시성 때문에 MyISAM SELECT가 느려지는 경우가 많음
이건 락을 걸때 어떤 방식으로 거느냐에 대한 문제로 테이블 전체를 락을 거는 것과 row 락을 거는 것에 대한 것입니다.
테이블 전체에 락을 걸면 끝날 때 까지 다른 쿼리가 들어오면 대기를 해야 됩니다.
● MyISAM이 빠른 경우는?
- 단일 스레드
- 읽기 전용
- 매우 단순한 테이블
- 인덱스 적음
- 트랜잭션, 동시성 필요 없음
위에서도 동시성에 대한 언급이 있듯이 동시성이 없는곳에서는 이노디비 보다는 아리아 디비 같은것 사용하는것이 더 좋습니다.
그렇기 때문에 내가 하는일이 어떤 일인지를 알고 방법을 선택 해야 합니다.
▷ 아리아(Aria)
MyISAM조차 쓰면 안 되는 곳에 Aria 사용하면 되는데 동시성 없는곳에 사용 하면 되고 MyISAM에 없는 "크래시 복구" 기능이 있습니다.
> 이렇게 말은 하지만 오래전에 이노디비 사용안할때 이것 사용하고 운영하고 다 그렇게 살았는데 지금도 큰 문제 없습니다.
> 아리아가 MyISAM 업그레이드 버전은 아니고 새로 만든것이라고 하네요.
결론은 트랜잭션이 필요하지 않은 상황에서는 동시성이 핵심적인 부분으로 이것이 필요하지 않다면 Aria 사용하면 됩니다.
그럼 마리아디비를 선택해야 된다는 것이 됩니다.
그런데 MySQL 최신에는 역인덱스 기능이 있는데 ... 마리아에는 없음.
그래서 오래전에 만든것들은 날짜의 경우 컬럼 하나 더 만들고 거꾸로 집어 넣고 정렬 할때는 이것을 사용 하곤 했는데 ... 용도에 따라 데이터베이스 선택도 잘 해야 합니다.
뿌리는 같은데 점점 가는 길이 조금씩 달라 지는것 같아 보입니다.
이렇게 수동으로 처리 하는것 처럼 내부적으로 거꾸로 처리 하도록 값을 바꿔서 넣어 주면 될것 같아 보이는데 실제 적용은 간단치 않으니 안되는 것이겠지요??