4.2 InnoDB 스토리지 엔진 아키텍처(3)

Double Write Buffer

InnoDB 스토리지 엔진의 리두 로그는 공간 낭비를 막기 위해 페이지의 변경된 내용만 기록한다. 이로인해 더티 페이지를 디스크 파일로 플러시할 때 일부만 기록되는 문제가 발생하면 그 페이지의 내용은 복구할 수 없을 가능성이 있다.

이런 현상을 파셜 페이지 또는 톤 페이지라고 하는데, 하드웨어의 오작동이나 시스템의 비정상 종료 등으로 발생할 수 있다.

파셜 페이지(Partial-Page)
데이터 베이스 페이지 중에서 데이터가 일부만 채워진 페이지. 레코드가 페이지의 크기보다 작을 때 발생하며, 레코드가 페이지를 벗어나지 않은 상태에서 페이지의 일부만 사용하게 된다.
톤 페이지(Tone-Page)
디스크에 기록 중인 페이지의 기록 작업이 중간에 중단되어 발생하는 문제. 페이지 일부가 디스크에 기록되지 않아 데이터 무결성이 손상되는 문제를 일으킬 수 있다.

InnoDB 스토리지 엔진은 이러한 문제를 막기 위해 Double-Write 기법을 활용한다.

Double Write 작동 방식

InnoDB 스토리지 엔진은 실제 데이터 파일에 변경 내용을 기록하기 전에 기록될 더티 페이지들을 묶어 시스템 테이블 스페이스의 DoubleWrite 버퍼에 기록한다.

더티 페이지 플러싱 중 오류등으로 서버가 종료되었다면 InnoDB 스토리지 엔진은 재시작 될 때 항상 Double Write 버퍼의 내용을 데이터 파일의 페이지로 복사하게 된다.

DoubleWrite 기능을 사용할지 여부는 Innodb_doublewrite 시스템 변수로 제어할 수 있다.

이처럼 DoubleWrite 버퍼는 데이터의 안정성을 위해 사용되는데, HDD처럼 자기 원판이 회전하는 저장 시스템에서는 한 번의 순차 디스크 쓰기를 하는 것으로 부담스럽지 않지만 SSD처럼 랜덤 IO와 순차 IO의 비용이 비슷한 저장 시스템에서는 부담스럽다.

SSD는 HDD와 다르게 내부적으로 물리적인 섹터 단위로 데이터를 읽고 쓰지 않는다. 따라서 메모리에 복사된 내용이 SSD의 섹터 크기보다 작은 경우에도(순차 디스크 쓰기) 여러번 기록되어야 한다.

하지만 데이터의 무결성이 매우 중요한 서비스에서는 DoubleWrite의 활성화를 고려하는 것도 좋다. 만약 데이터베이스 서버의 성능을 위해 InnoDB 리두 로그 동기화 설정(innodb_flush_log_at_trx_commit 시스템 변수)을 1이 아닌 값으로 설정했다면, DoubleWrite도 비활성화 하는 것이 좋다.

innodb_flush_log_at_trx_commit
0: 커밋 후 로그 버퍼를 디스크에 즉시 플러시 하지 않고, 로그 버퍼가 일정 수준 채워지거나 데이터베이스 서버가 종료될 때 플러시한다. 데이터 일관성이 보장되지 않을 수 있다.
1(default): 컷밋 후 로그 버퍼를 디스크에 즉시 플러시한다. 데이터 일관성은 보장하지만 디스크 IO가 부하를 발생시킬 수 있다.
2: 커밋 후 로그 버퍼를 디스크에 즉시 플러시 하지 않고, 로그를 별도 파일에 쓴 후 파일을 주기적으로 플러시 한다. 0과 1의 중간 정도로 데이터 일관성과 디스크 IO 부하 감소를 균형있게 유지할 수 있다.

언두 로그

InnoDB 스토리지 엔진은 트랜잭션과 격리 수준을 보장하기 위해 DML로 변경되기 이전 버전의 데이터를 별도로 백업한다. 이렇게 백업된 데이터를 언두 로그(Undo Log)라고 한다.

트랜잭션 보장
트랜잭션이 롤백되면 트랜잭션 도중 변경된 데이터를 변경 전 데이터로 복구해야 하는데, 이때 언두 로그에 백업해둔 이전 버전의 데이터를 이용해 복구한다.
격리 수준 보장
특정 커넥션에서 데이터를 변경하는 도중 다른 커넥션에서 데이터를 조회하면 트랜잭션 격리 수준에 맞게 변경중인 레코드를 읽지 않고 언두 로그에 백업해둔 데이터를 읽어서 반환하기도 한다.

언두 로그 모니터링

언두 로그로 인해 여러가지 성능 이슈가 발생할 수 있어 모니터링이 필요하다.

대용량 처리 트랜잭션
1억 건의 레코드가 저장된 100GB 크기의 테이블을 DELETE로 삭제한다고 가정했을때, 언두 로그에 삭제전 값을 저장해야 하므로 언두 로그 공간은 100GB가 된다.
장시간 활성화된 트랜잭션
트랜잭션이 완료됐다고 해서 해당 트랜잭션이 생성한 언두 로그를 즉시 삭제할수 없을 수 있다. 먼저 시작된 트랜잭션보다 이후 발생한 트랜잭션이 완료된 경우, 먼저 시작된 완료된 트랜적션이 완료되기 전 까지 언두 로그는 삭제되지 않는다. 이러한 경우 언두 로그의 이력을 필요한 만큼 스캔해야만 필요한 레코드를 찾을 수 있기 때문에 쿼리의 성능이 전반적으로 떨어질 수 있다.

1
2
3
4
5
6
7
8
9
/* MySQL 모든 버전 */
SHOW ENGING INNODB STATUS \G

/* MySQL 8.0 */
SELECT count
FROM information_schema.innodb_metrics
WHERE SUBSYSTEM='transaction' 
    AND NAME='trx_rseg_history_len'
;

MySQL 서버에서 실행되는 INSERT, UPDATE, DELETE 문장이 얼마나 많은 데이터를 변경하느냐에 따라 평상시 언두 로그 건수는 상이할 수 있어, 안정적인 시점의 언두 로그 건수를 확인하고 이를 기중으로 언두 로그의 급증 여부를 모니터링하는 것이 좋다.

MySQL 서버에서 INSERT 문장으로 인한 언두 로그와 UPDATE, DELETE 문장으로 인한 언두 로그는 별도로 관리된다. UPDATE, DELETE 문장으로 인한 언두 로그는 MVCC와 데이터 복구(롤백 등)에 모두 사용되지만, INSERT 문장으로 인한 언두 로그는 롤백, 데이터 복구만을 위해 사용된다.

언두 테이블스페이스 관리

언두 로그가 저장되는 공간을 언두 테이블스페이스(Undo Tablespace)라고 한다.

MySQL 5.6 이전 버전에서는 언두 로그가 모두 시스템 테이블스페이스(ibdata.idb)에 저장되었었지만, 시스템 테이블스페이스의 언두 로그는 MySQL서버가 초기화될 때 생성되기 때문에 확장의 한계가 있었다. 이에 따라 5.6 버전에서는 innodb_undo_tablespaces 시스템 변수가 도입되어 별도 로그 파일을 사용할 수 있게 되었고, 8.0으로 업그레이드되면서 언두 로그는 항상 시스템 테이블스페이스 외부의 별도 로그 파일에만 기록되도록 개선되었다.

하나의 언두 테이블스페이스는 1~128개의 롤백 세그먼트를 가지며, 롤백 세크먼트는 1개 이상의 언두 슬롯(Undo Slot)을 가진다.

최대 동시 처리 가능한 트랜잭션의 개수는 다음 수식으로 예측할 수 있다.

(InnDB 페이지 크기) / 16 * (롤백 세그먼트 개수) * (언두 테이블 스페이스 수)

InnoDB 기본 설정(innodb_undo_tablespace=2, innodb_rollback_segments=128)을 사용한다면 131,072개 정도의 트랜잭션이 동시에 처리 가능해진다. 일반적인 서비스에서 이 정도까지 동시 트랜잭션이 필요하진 않겠지만 기본값으로 해서 크게 문제될 건 없다.

언두 로그 슬롯이 부족한 경우에는 트래잭션을 시작할 수 없는 심각한 문제가 발생하기 때문에 적절히 정해야 한다.

MySQL 8.0 부터 CREATE UNDO TABLESPACE나 DROP TABLESPACE같은 명령으로 새로운 언두 테이블 스페이스를 동적으로 추가하고 삭제할 수 있게 개선되었다.

언두 테이블스페이스 공간을 필요한 만큼만 남기고 불필요하거나 과도하게 할당된 공간을 운영체제로 반납하는 것을 ‘Undo tablespace truncate’라고 하며 자동, 수동 두가지 방법이 있다.

체인지 버퍼

RDBMS에서 레코드가 추가, 변경될 때 데이터 파일을 변경하는 작업뿐 아니라 해당 테이블에 포함된 인덱스를 업데이트하는 작업도 필요하다. 인덱스를 업데이트하는 작업은 랜덤하게 디스크를 읽는 작업이 필요하므로 테이블에 인덱스가 많다면 상당히 많은 자원을 소모하게 된다. 따라서 InnoDB는 변경해야 할 인덱스 페이지가 버퍼풀에 있으면 바로 업데이트를 수행하지만, 그렇지 않고 디스크로부터 읽어와서 업데이트해야 한다면 이를 즉시 실행하지 않고 임시 공간에 저장해 두고 바로 사용자에게 결과를 반환하는 형태로 성능을 향상시키게 되는데, 이때 사용하는 임시 메모리 공간을 체인지 버퍼(Change Buffer)라고 한다.

사용자에게 결과를 반환하기 전에 반드시 중복 여부를 체크해야 하는 유니크 인덱스는 체인지 버퍼를 사용할 수 없다.

체인지 버퍼에 임시로 저장된 인덱스 레코드 조각은 이후 백그라운드 스레드에 의해 병합되는데, 이 스레드를 체인지 버퍼 머지 스레드라고 한다.

MySQL 5.5 이전 버전까지는 INSERT 작업에 대해서만 이러한 버퍼링이 가능했는데, 이후 조금씩 개선되며 INSERT, UPDATE, DELETE로 인해 키를 추가하거나 삭제하는 작업에 대해서도 버퍼링이 될 수 있게 개선되었다.

또한 innodb_change_buffering이라는 시스템 변수가 새로 도입되어 작업의 종류별로 체인지 버퍼를 활성화할 수 있으며, 체인지 버퍼가 비효일적일 때는 체인지 버퍼를 사용하지 않게 설정할 수 있게 개선되었다.

all: 모든 인덱스 관련 작업을 버퍼링(inserts + deletes + purges)
none: 버퍼링 안함
inserts: 인덱스에 새로운 아이템을 추가하는 작업만 버퍼링
deletes: 인덱스에서 기존 아이템을 삭제하는 작업(삭제됐다는 마킹 작업)만 버퍼링
changes: 인덱스에 추가하고 삭제하는 작업만(inserts + deletes) 버퍼링
purges: 인덱스 아이템을 영구적으로 삭제하는 작업만 버퍼링(백그라운드 작업)

체인지 버퍼는 기본적으로 InnoDB 버퍼풀로 설정된 메모리 공간의 25%까지 활용할 수 있게 설정돼있으며, 필요하다면 50%까지 설정할 수 있다. innodb_change_buffer_max_size 시스템 변수에 비율을 조정하여 바꿀 수 있다.

리두 로그 및 로그 버퍼

리두 로그는 트랜잭션의 4가지 요소인 ACID 중에서 D(Durable)에 해당하는 영속성과 가장 밀점하게 연관돼 있다. 리두 로그는 하드웨어나 소프트웨어 등 문제로 인해 MySQL 서버가 비정상적으로 종료됐을 때 데이터 파일에 기록되지 못한 데이터를 잃지 않게 해주는 안전장치이다.

대부분 데이터베이스 서버는 데이터 변경 내용을 로그로 먼저 기록한다. 대부분 DBMS에서 데이터 파일은 쓰기보다 읽기 성능을 고려한 자료 구조를 가지고 있기 때문에 데이터 파일 쓰기는 디스크의 랜덤 액세스가 필요하여 상대적으로 큰 비용이 필요하다.

이로 인한 성능 저하를 막기 위해 쓰기 비용이 낮은 자료구조인 리두 로그를 가지고 있으며, 비정상 종료가 발생하면 리두 로그의 내용을 이용해 데이터 파일을 다시 서버가 종료되기 직전 상태로 복구한다.

또한 성능을 위해 리두 로그를 버퍼링 할 수 있는 InnoDB 버퍼풀이나, 리두 로그를 버퍼링할 수 있는 로그 버퍼와 같은 자료 구조도 가지고 있다.

MySQL 서버가 비정상으로 종료되는 경우 InnoDB 스토리지 엔진의 데이터 파일은 두 가지 일관되지 않은 데이터를 가질 수 있다.

커밋됐지만 데이터 파일에 기록되지 않은 데이터
롤백됐지만 데이터 파일에 이미 기록된 데이터

리두로그를 활용하여 변경이 커밋, 롤백, 트랜잭션의 실행 중간 상태였는지 확인하고, 적절히 처리한다.

데이터베이스 서버에서 리두 로그는 트랜잭션이 커밋되면 즉시 디스크로 기록되도록 시스템 변수를 설정하는 것을 권장한다. 그래야만 서버가 비정상적으로 종료되었을때 직전까지의 트랜잭션 커밋 내용이 리두 로그에 기록될 수 있고, 그 리두 로그를 이용해 장애 직전 시점까지 복구가 가능해진다.

하지만 트랜잭션이 커밋될 때마다 리두 로그를 디스크에 기록하면 부하가 생길 수 있어, InnoDB 스토리지 엔진에서 리두 로그를 어느 주기로 디스크에 동기화할지를 결정하는 innodb_flush_log_trx_commit 시스템 변수를 제공한다.

0: 1초에 한 번씩 리두 로그를 디스크로 기록하고 동기화를 실행한다. 서버가 비정상 종료되면 최대 1초 동안의 트랜잭션은 커밋됐더라도 데이터는 사라질 수 있다.
1: 매번 트랜잭션이 커밋될 때마다 디스크로 기록되고 동기화까지 수행한다.
2: 트랜잭션이 커밋될 때마다 디스크로 기록은 되지만 실질적인 동기화는 1초에 한번씩 실행된다. 커밋이 되면 변경 내용이 운영체제의 메모리 버퍼로 기롤되는 것이 보장되기 때문에 MySQL 서버가 비정상 종료되더라도 트랜잭션 데이터는 사라지지 않는다.

리두 로그 파일들의 전체 크기는 버버풀의 효율성을 결정하기 때문에 신중히 결정해야한다. 리두 로그 파일의 크기는 innodb_log_file_size 시스템 변수로 결정하며, innodb_log_files_in_group 시스템 뼌수는 리두 로그 파일 개수를 결정한다.

리두 로그 파일의 전체 크기를 버퍼풀의 크기에 맞게 설정해야 적절히 변경된 내용을 버퍼풀에 모아 한번에 디스크에 기록할 수 있다.

ACID는 데이터베이스에서 트랜잭션의 무결성을 보장하기 위해 꼭 필요한 4가지 요소(기능)을 의미한다.
A(Atomic): 트랜잭션은 원자성 작업이어야 함.
C(Consistent): 일관성
I(Isolated): 격리성
D(Durable): 영속성. 한 번 저장된 데이터는 지속적으로 유지되어야 함.

리두 로그 아카이빙

MySQL 8.0부터 InnoDB 스토리지 엔진의 리두 로그를 아카이빙 할 수 있는 기능이 추가됐다.

백업 툴이 리두 로그 아카이빙을 사용하려면 먼저 MySQL 서버에서 아카이빙된 리두 로그가 저장될 디렉터리를 innodb_redo_log_archive_dirs 시스템 변수에 설정해야 하며, 디렉터리는 운영체제의 MySQL 서버를 실행하는 유저만 접근이 가능해야 한다.

1
2
3
4
mkdir /var/log/mysql_redo_archive
cd /var/log/mysql_redo_archive
mkdir 20230413
chmod 700 20230413

1
SET GLOBAL innodb_redo_log_archive_dirs='backup:/var/log/mysql_redo_archive';

디렉터리가 준비되면 리두 로그 아카이빙을 시작하도록 innodb_redo_log_archive_start UDF(사용자 정의 함수)를 실행한다. 해당 UDF는 리두 로그를 아카이빙할 디렉터리에 대한 레이블과 선택적으로 서브 디렉터리 이름 총 두가지의 매개 변수를 받는다.

1
DO innodb_redo_log_archive_start('backup', '20230413');

리두 아카이빙을 종료할 때는 innodb_redo_log_archive_stop UDF를 실행한다.

1
DO innodb_redo_log_archive_stop();

innodb_redo_log_archive_start UDF를 실행한 세션의 연결이 끊어지면 InnoDB 스토리지 엔진은 리두 로그 아카이빙을 멈추고 아카이빙 파일도 자동으로 삭제하므로 커넥션을 유지해야 하고, innodb_redo_log_archive_stop UDF를 호출하여 정상적으로 종료돼야 한다.

리두 로그 활성화 및 비활성화

InnoDB 스토리지 엔진의 리두 로그는 MySQL 서버가 비정상 종료됐을때 데이터 파일에 기록되지 못한 트랜잭션을 복구하기 위해 항상 활성화되어있다. MySQL 서버에서 트랜잭션이 커밋돼도 데이터 파일은 즉시 디스크로 동기화되지 않는 반면, 리두 로그는 항상 디스크로 기록된다.

MySQL 8.0 버전부터 수동으로 리두 로그를 비활성화 할 수 있어, 대용량 데이터를 한번에 적재하는 경우 사용하여 적재 시간을 단축할 수 있다.

어댑티브 해시 인덱스

어댑티브 해시 인덱스는 InnoDB 스토리지 엔진에서 사용자가 자주 요청하는 데이터에 대해 자동으로 생성하는 인덱스로, innodb_adaptive_hash_index 시스템 변수를 이용하여 활성화, 비활성화 할 수 있다.

MySQL B-Tree Index

InnoDB 스토리지 엔진의 대표적인 인덱스는 B-Tree로 데이터는 PK 순으로 정렬되어 관리되고, Secondary Key는 인덱스키 + PK 조합으로 정렬되어 있다. 특정 데이터를 찾기 위해 Secondary Key에서 PK를 찾고, 찾은 PK를 통해 원하는 데이터를 찾는 형태로 처리된다.

PK 사용시 데이터에 접근되는 비용은 O(logN)이고, Secondary Key를 사용해 데이터에 접근은 PK에 대한 접근도 필요하므로 2 * O(logN)이다.

따라서 B-Tree 자료구조 특성으로 데이터가 많아진다 하더라도 탐색 비용이 크게 증가하지 않지만, 동시에 많은 스레드에서 탐색 작업이 발생할 경우 Lock 등으로 인해 성능 저하가 발생할 수 있다.

어댑티브 해시 인덱스는 B-Tree의 검색 시간을 줄여주기 위해 도입된 기능으로, 자주 읽히는 데이터 페이지의 키 값을 이용해 해시 인덱스를 만들고, 필요할 때마다 어댑티브 해시 인덱스를 검색해서 레코드가 저장된 데이터 페이지를 즉시 찾아갈 수 있다.

구조

MySQL Adaptive Hash Index

해시 인덱스는 인덱스 키 값과 해당 인덱스 키 값이 저장된 데이터 페이지 주소의 쌍으로 관리된다.

인덱스 키 값:
B-Tree 인덱스의 고유번호 + B-Tree 인덱스의 실제 키 값
- 인덱스의 고유번호가 포함되는 이유는 InnoDB 스토리지 엔진에서 어댑티브 해시 인덱스는 하나만 존재하기 때문이다.
데이터 페이지 주소:
실제 키 값이 저장된 데이터 페이지의 메모리 주소, 버퍼풀에 로딩된 페이지의 주소를 의미

어댑티브 해시 인덱스는 버퍼풀에 올려진 데이터 페이지에 대해서만 괸리되고, 버퍼풀에서 해당 데이터 페이지가 없어지면 어댑티브 해시 인덱스에서도 해당 페이지의 정보는 사라진다.

성능

CPU 사용률 변화

어댑티브 해시 인덱스를 활성화 후 처리량은 2배 가까이 늘었음에도 불구하고 CPU 사용량은 오히려 떨어진다.

세마포어 변화

InnoDB 내부잠금(세마포어)의 횟수도 획기적으로 줄어든다.

추가로 MySQL 8.0 부터는 내부 잠금을 줄이기 위해 어댑티브 해시 인덱스의 파티션 기능을 제공하며 innodb_adaptive_hash_index_parts 시스템 변수를 통해 파티션 개수를 변경할 수 있다(기본값 8개).

어댑티브 해시 인덱스가 성능에 많은 도음이 된다면 파티션 개수를 더 많이 설정하는 것도 도움이 될 수 있다.

한계

상황에 따라 어댑티브 해시 인덱스가 성능 향상에 크게 도움이 되지 않는 경우도 있다.

성능 향상에 도움이 되는 경우
- 디스크의 데이터가 InnoDB 버퍼풀 크기와 비슷한 경우(디스크 읽기가 많지 않은 경우)
- 동등 조건 검색(동등 비교 및 IN 연산)이 많은 경우
- 쿼리가 일부 데이터에만 집중 되는 경우
성능 향상에 크게 도움이 되지 않는 경우
- 디스크 읽기가 많은 경우
- 특정 패턴의 쿼리가 많은 경우(JOIN, LIKE 패턴 검색)
- 매우 큰 데이터를 가진 테이블의 레코드를 폭넓게 읽는 경우

어댑티브 해시 인덱스는 데이터 페이지를 메모리(버퍼풀) 내에서 접근하는 것을 더 빠르게 만드는 기능으로 데이터 페이지를 디스크에서 읽어오는 경우가 많은 경우 데이터베이스 서버에서는 큰 도움이 되지 않는다.

어댑티브 해시 인덱스 또한 메모리를 사용하며, 때로는 상당히 큰 메모리 공간을 사용할 수 있다.
데이터 페이지의 인덱스 키가 해시 인덱스로 만들어져야 하기 때문에 불필요한 경우 제거되어야 한다.
활성화되면 InnoDB 스토리지 엔진이 필수적으로 검색에 활용해야 하기 때문에 불필요한 접근이 발생할 수 있다.

주의할 점

테이블 삭제(DROP), 변경(ALTER)시 해당 테이블이 가진 모든 데이터 페이지의 내용을 어댑티브 해시 인덱스에서 제거해야한다. 이로 인해 테이블이 삭제되거나 스키마가 변경되는 동안 상당히 많은 CPU 자원을 사용하게되어 데이터베이스 서버의 처리 성능이 떨어진다.

모니터링

MySQL 서버의 상태 값들을 통해 어댑티브 해시 인덱스가 불필요한 오버헤드만 만들고 있는지 확인할 수 있다.

1
2
3
4
5
6
7
8
SHOW ENGINE INNODB STATUS\G

/*
Hash table size 8747, node heap has 1 buffers(s)
Hash table size 8747, node heap has 0 buffers(s)
...
1.03 hash searches/s, 2.64 non-hash searches/s
/*

searches: 쿼리가 처리되기 위해 내부적으로 키 값의 검색이 몇 번 실행되었는지를 의미함

어댑티브 해시 인덱스의 효율은 검색 횟수가 아니라 해시 인덱스 히트율과 인덱스가 사용 중인 메모리 공간, 서버의 CPU 사용량을 종합해서 판단해야 한다.

위 실행 쿼리 결과에서는 28% 정도가 어댑티브 해시 인덱스를 이용했다는 것을 알 수 있는데, 서버의 CPU 사용량이 100%에 근접한다면 효율적이라고 볼 수 있다. 하지만 CPU 사용량이 낮고 어댑티브 해시 인덱스의 메모리 사용량이 높다면 비활성화하여 버퍼풀이 더 많은 메모리를 사용할 수 있게 유도하는 것도 좋은 방법이다.

어댑티브 해시 인덱스의 메모리 사용량은 performance_schema를 이용해서 확인 가능하다.

1
2
3
4
5
SELECT EVENT_NAME
    ,CURRENT_NUMBER_OF_BYTES_USED
FROM performance_schema.memory_summary_global_by_event_name
WHERE EVENT_NAME='memory/innodb/adaptive hash index'
;

MyISAM, MEMORY 스토리지 엔진 비교

MyISAM

MySQL 5.5부터는 InnoDB 스토리지 엔진이 기본 스토리지 엔진으로 채택 되었지만, 이전까지는 MyISAM이 기본 스토리지 엔진으로 사용되는 경우가 많았다.

MySQL 서버의 시스템 테이블의 기본 스토리지 엔진 MySQL 8.0 부터는 MyISAM이 기본 설정되었던 서버의 시스템 테이블(사용자 인증 관련 정보, 복제 관련 정보가 저장된 mysql DB의 테이블) 등 서버의 모든 기능을 InnoDB 스토리지 엔진으로 교체되었다.
전문 검색 및 공간 좌표 검색 기능 제공. InnoDB 스토리지 엔진에서도 전문 검색과 공간 좌표 검색 기능을 모두 지원하도록 개선되었다.

이러한 이유로 MyISAM 스토리지 엔진은 InnoDB 스토리지 엔진으로 대체될 것으로 예상된다.

MEMORY

MEMORY 스토리지 엔진이 메모리라는 이름 때문에 과대 평가를 받는 경우가 있다.

단일 스레드 처리 성능 단일 스레드 처리 성능은 MEMORY 스토리지 엔진이 빠를 수 있으나, MySQL 서버는 일반적으로 온라인 트랜잭션 처리를 위한 목적으로 사용되어 동시 처리 성능이 매우 중요하다. MEMORY 스토리지 엔진에서 동시에 많은 클라이언트 쿼리 요청이 실행되는 상황이라면 테이블 수준의 잠금으로 인해 InnoDB 스토리지 엔진을 따라갈 수 없다.
임시 테이블 용도로 활용 MySQL 5.7 버전까지 내부 임시 테이블 용도로 활용되었으나, 가변 길이 타입의 컬럼을 지원하지 않는다는 문제점으로 MySQL 8.0 부터는 TempTable 스토리지 엔진이 대체되어 사용된다.

이러한 이유로 MEMORY 스토리지 엔진을 선택해서 얻을 수 있는 장점이 없어져, 향후 버전에서는 제거될 것으로 예상된다.