MySQL 몇가지 특성
MySQL 엔진 + 스토리지 엔진
메모리 & 파일 구조
Adaptive_Hash_Index
B-Tree의 탐색 비효율(보조 인덱스를 수행할때 어차피 키를 찾고 다시 서칭해야하는
이슈나 밸런스가 깨져서 효율적인 탐색이 불가한 상태에서의 검색)
을 극복하기 위해, 인덱스에 자주 사용되는 데이터를 해쉬로 가지고있음
이것은 MySQL이 판단해서 해시로 가지고 있는 값이고 어떤 것을 태울지 모름, 탈때는 수행속도가 아주 빠르고 효율적임 옵션으로 제어 가능.테이블 DROP 시 해당 인덱스도 삭제되기때문에
이슈 발생(성능 영향) 여지 있음
Change Buffer==Insert Buffer
보조 인덱스의 변경에 고비용에 대비한 영역, "데이터 버퍼에서 해당 인덱스에 데이터가 없으면"
디스크로 가는것이 아닌 버퍼를 활용하여 비용을 줄임
Redo Log
변경된 페이지의 트랜잭션 내용이 메모리에 상존하다가 갑자기 서버가 크래시나 다운이 되어
디스크에 채 쓰지 못하는 상황이 발생할때, 대비하도록 Redo Log가 설정값으로 주기적으로 기록(log buffer 내 redo buffer에 선 기록 후 디스크로) 딱 FLUSH 직전 변경분만 가지고있음
Undo Log
데이터의 변경 직전 데이터를 보관하는데, MVCC 사용을 위한 장치
동시성을 향상시키나 변경시 버퍼 내 메모리 리소스를 사용하고 파일에 작성하므로
트랜잭션 지연(롱 트랜잭션)이나, 대용량일 경우 문제(메모리 경합)가 더욱 커질수 있음
메모리에 의존하여 계속해서 사용량을 증가시키거나 리소스를 사용하므로 때문에,
등장한것이 5.7에 Undo 테이블 스페이스 역시 log buffer 내 undo log buffer 를 먼저 쓰고
파일을 씀
Double Write Buffer
5%~10% 성능 손해를 감수하고 메모리에서 FLUSH 된 "데이터"를
이곳에도 저장하여, OS에 디스크 쓰기 단위가 달라 발생하는 충돌이나 장애 발생하여 "디스크에 변경이력을 저장하지 못했을때" 이곳에서 대조해서 복구
InnoDB 특징