Amazon RDS for MySQL과 Amazon Aurora MySQL의 TempTable 스토리지 엔진 사용

2023년 8월 기준으로 Aurora MySQL 에 영향을 주는 MySQL: 8.0.28 커뮤니티 버전의 변경된 파라미터를 반영해서 새롭게 내용이 업데이트 되었습니다.

MySQL 8.0은 쿼리 처리 속도를 높이기 위해 디폴트 내부 임시 테이블(internal temporary table)을 위한 신규 스토리지 엔진으로 TempTable을 도입했습니다. MySQL 쿼리 옵티마이저는 복잡한 쿼리를 처리하는 동안 중간 데이터 셋을 저장하기 위해 내부적으로 임시 테이블(temporary table)을 만듭니다. AWS에서 Amazon RDS for MySQL 을 사용하여 MySQL 8.0을 사용 할 수 있습니다. 하드웨어 프로비저닝, 데이터베이스 설정, 패치, 백업과 같은 시간 소모적인 관리 작업을 자동화하는 MySQL Community Edition(CE)용의 관리 서비스입니다. 또한 클라우드용으로 구축된 MySQL 이나 PostgreSQL 호환 데이터베이스인 Amazon Aurora를 사용하여 MySQL 8.0 호환 데이터베이스 클러스터를 사용 할 수 있습니다. 이 데이터베이스는 기존 엔터프라이즈 데이터베이스의 성능, 가용성, 오픈 소스 데이터베이스의 단순화와 비용 효율성을 구현할 수 있습니다. 이번 글을 통해 Amazon RDS for MySQL DB 인스턴스와 Amazon Aurora MySQL DB 클러스터에서 TempTable 스토리지 엔진을 사용하는 모범 사례를 설명 드리겠습니다. 내부 임시 테이블이 관련되어 있고 메모리나 디스크 스토리지 할당이 필요할 때 쿼리 성능에 영향을 미치는 일반적인 문제와 관리형 데이터베이스 서비스에서 고려해야 할 사항에 대해서 설명 드리겠습니다.

MySQL 에서 내부 임시 테이블을 처리하기

일반적으로 내부 임시 테이블(internal temporary table)은 최적의 쿼리 성능을 위해 먼저 메모리에 생성 됩니다. 과도한 메모리 할당을 방지하기 위해 MySQL 에서는 메모리 제한 값을 설정하는 파라미터를 제공합니다. 설정된 제한 값에 도달하면 내부 임시 테이블이 디스크 스토리지로 오버플로우됩니다. MySQL은 디스크 스토리지의 내부 임시 테이블과 메모리의 내부 임시 테이블에 대해 다른 스토리지 엔진을 지정할 수 있습니다.

8.0 버전 이전에는 MySQL은 메모리 내의 내부 임시 테이블에서 디폴트로 MEMORY 스토리지 엔진을 사용했습니다. MySQL 8.0버전에서는 이를 TempTable 스토리지 엔진으로 대체했지만 기존의 MEMORY 스토리지 엔진으로 설정하는 옵션도 제공합니다. TempTable 스토리지 엔진의 관리 편의성은 이를 사용하는 모든 세션이 Memory Pool 을 사용한다는 것입니다. temptable_max_ram으로 설정된 메모리 제한 값은 동시 세션에서 사용되는 메모리의 합계에 대해 적용됩니다. 이는 이전의 MEMORY 스토리지 엔진에서 더 작은 tmp_table_size와 max_heap_table_size로 설정된 메모리 제한이 세션에 따라 테이블 별로 적용되는 것과는 다릅니다. TempTable 스토리지 엔진은 자체 디스크 오버플로우 메커니즘도 가지고 있습니다. 메모리 매핑 임시 파일(Memory-Mapped Temporary File)이나 InnoDB On-Disk 내부 임시 테이블로 오버플로우 되도록 구성할 수 있습니다. 메모리 매핑 파일(memory-mapped file)은 파일과 메모리 공간 간의 매핑 정보를 제공하여 파일 읽기와 쓰기 작업을 최적화 시킵니다. 메모리 제한 외에도 이 두 개의 별도 오버플로우 경로는 내부 임시 테이블 스토리지 엔진의 차별화된 특성과 쿼리 성능에 직접적인 영향을 미칠 수 있습니다.

파라미터 구성의 차이

다음의 다이어그램은 MySQL CE releases 의 최근 릴리즈 중에 하나인 MySQL 8.0.28 에서의 TempTable 스토리지 엔진의 네가지 파라미터 동작방식에 대해서 설명하고 있습니다.

파라미터의 설명은 다음과 같습니다.

internal_tmp_mem_storage_engine은 TempTable(디폴트 값) 이나 MEMORY로 값을 설정해서 메모리에 생성되는 내부 임시 테이블에 대한 스토리지 엔진을 정의할 수 있습니다. 이 파라미터는 TempTable 스토리지 엔진이 도입된 MySQL 8.0.2 버전부터 추가되었습니다.
temptable_max_ram 은 MySQL 8.0.2에서 도입되었으며TempTable 스토리지 엔진에서 사용할 수 있는 최대 메모리 량을 설정합니다.
temptable_max_mmap은 MySQL 8.0.23에 도입되었으며 TempTable 스토리지 엔진이 메모리 매핑 임시 파일(Memory-mapped Temporary File)에 할당할 수 있는 최대 디스크 스토리지 양을 정의합니다. 0으로 설정하면 메모리 매핑 임시 파일 사용이 비활성화되어져 오버플로우 되면 InnoDB 온디스크 내부 임시 테이블로 쓰여집니다.
tmp_table_size는 MySQL 8.0.28부터 TempTable 스토리지 엔진에서 만들어지는 개별 내부 임시 테이블의 최대 크기를 설정합니다.

RDS MySQL을 사용하는 경우 해당 파라미터의 변경 사항을 확인해주십시오. 이유는 TempTable 스토리지 엔진이 계속 개선되면서 시간이 지나면서 많은 변경이 있었습니다. RDS for MySQL은 MySQL 8.0 CE의 다양한 마이너 버전을 지원하므로 각 버전에서 사용 가능한 파라미터가 다를 수 있습니다. DB 파라미터 그룹에서 이 내용을 확인할 수 있습니다.

Aurora MySQL 3.0 버전은 MySQL 8.0.23 CE 이상과 호환됩니다. 사용하는 Aurora MySQL 버전과 Aurora DB 클러스터의 모든 DB 인스턴스에 균등한 설정을 적용할지 여부에 따라 DB 클러스터 그룹이나 인스턴스 파라미터 그룹에서 이러한 모든 파라미터를 설정할 수 있습니다. 그러나 Aurora DB 클러스터에서만 지원되는 스토리지 아키텍처로 인해 Aurora 복제본(리더) DB 인스턴스의 내부 임시 테이블 동작이 다릅니다.

Aurora DB 클러스터에는 모든 DB 인스턴스에서 공유하는 클러스터 볼륨과 각 DB 인스턴스에 연결된 로컬 스토리지 두 가지 유형의 스토리지를 가집니다. Aurora Primary(Writer) DB 인스턴스에서 TempTable 스토리지 엔진은 다음과 같이 Overflow 과정이 수행됩니다.

메모리 매핑 임시 파일(Memory-mapped Temporary File)이 로컬 스토리지에 생성됩니다.
InnoDB 온디스크 내부 임시 테이블이 공유 클러스터 볼륨에 저장됩니다.

Aurora 복제본(리더) DB 인스턴스는 공유 클러스터 볼륨에 대한 쓰기 권한이 없으므로 클러스터 볼륨에 InnoDB 온디스크 내부 임시 테이블을 생성할 수 없습니다. 결과적으로 Aurora 복제본의 파라미터에 다음과 같은 제약 조건이 적용됩니다.

internal_tmp_mem_storage_engine파라미터는 내부적으로 TempTable 스토리지 엔진으로만 설정되고 이를 수정할 수 없습니다. 파라미터 그룹에서 MEMORY 스토리지 엔진으로 설정하려고 하면 변경 사항이 적용되지 않습니다.
temptable_use_mmap은 내부적으로 1로 설정되며 수정할 수 없습니다. 파라미터 그룹에 다른 값을 적용하면 변경 사항이 적용되지 않습니다.
temptable_max_mmap은 0으로 설정할 수 없습니다. 파라미터 그룹에서 0으로 설정하려고 하면 내부적으로 기본값인 1GB로 재설정됩니다.
tmp_table_size는 Aurora MySQL 3.04.0 버전부터 TempTable 스토리지 엔진에서 사용할 수 있지만 이를 적용하기 위해서 Aurora 파라미터인 aurora_tmptable_enable_per_table_limit을 활성화해야 합니다.
aurora_tmptable_enable_per_table_limit을 0으로 설정하면 tmp_table_size는 Aurora Primary(Writer) DB 인스턴스나 복제본 DB 인스턴스에 영향을 미치지 않습니다. 이는 디폴트 설정입니다.
aurora_tmptable_enable_per_table_limit을 1로 설정하면 tmp_table_size는 Aurora Primary(Writer) DB 인스턴스와 Aurora 복제본 DB 인스턴스에서 내부 임시 테이블에 할당된 최대 메모리 크기를 제한할 수 있습니다. 디폴트 값은 16M입니다. 내부 임시 테이블 크기가 Aurora 복제본(Reader) DB 인스턴스에서 tmp_table_size의 제한을 초과하면 쿼리가 오류 메시지와 함께 실패합니다.

요약하자면 Aurora DB 클러스터의 Primary(Writer) DB 인스턴스는 MySQL 8.0.28 CE와 동일한 4개의 구성 파라미터를 사용할 수 있지만 Aurora 복제본(Reader) DB 인스턴스는 다음 다이어그램에서 볼 수 있듯이 temptable_max_ram과 temptable_max_mmap의 두 파라미터만이 사용됩니다.

튜닝 전략

내부 임시 테이블은 메모리나 스토리지 또는 둘 다 할당되어 데이터를 처리합니다. 내부 임시 테이블 스토리지 엔진에 필요한 리소스 사용량은 워크로드에 따라 다릅니다. 그러나 RDS DB 인스턴스는 DB 인스턴스 클래스와 스토리지 아키텍처에 따라서 정해진 시스템 리소스 용량이 있습니다. 올바른 튜닝 전략은 쿼리가 확장되고 예상 성능 목표를 충족할 수 있도록 시스템 리소스의 사용량과 현재의 설정된 리소스 간의 균형을 맞춰야 합니다.

메모리 사용

메모리에서 데이터를 처리하는 것은 항상 디스크로 Overflow 되는 것보다 빠릅니다. TempTable 스토리지 엔진의 메모리 제한 값인 temptable_max_ram은 MySQL CE에서 기본적으로 1GB로 설정되며 Amazon RDS for MySQL과 Aurora MySQL에서도 마찬가지로 적용됩니다. 이것은 db.r5 나 db.r6g와 같은 Memory Optimized DB Instance Class를 사용하는 대부분 DB 인스턴스에 있어서 보수적인 설정입니다. 워크로드에 따라 이 파라미터 값을 조정하고 DB 인스턴스의 메모리 용량인 DBInstanceClassMemory값에 따라 크기를 조정하는 공식을 사용할 수 있습니다. 이것은 동적 파라미터이므로 RDS 인스턴스를 재 부팅하지 않고도 반영할 수 있습니다.

temptable_max_ram을 큰 값으로 설정하면 메모리가 부족해질 위험이 커질 수 있어 특히 메모리 용량이 작은 일부 db.t2 나 db.t3 인스턴스 클래스에서 유의해야 합니다. 따라서 Amazon Aurora MySQL은 db.t3.medium 나 db.t3.large 인스턴스 클래스의 디폴트 값을 16MB로 조정했습니다. DB 인스턴스의 메모리 사용량이 예상 범위 내에 있는지 확인하려면 Amazon CloudWatch 매트릭 지표인 FreeableMemory를 모니터링하는 것이 유용합니다.

스토리지 사용량

디스크 오버플로는 처리할 데이터가 현재 메모리보다 훨씬 더 큰 경우 쿼리를 계속 처리할 수 있도록 하는 처리 방식입니다. 일반적으로 내부 임시 테이블을 사용하는 쿼리가 동시 워크로드에서 발생되거나 많은 양의 데이터를 처리할 때 발생합니다. TempTable 스토리지 엔진에는 두 개의 오버플로 과정이 있습니다. 기본적으로 메모리 제한에 도달하면 먼저 메모리 매핑 임시 파일로 오버플로 됩니다. temptable_max_mmap으로 설정된 메모리 매핑 임시 파일에 대한 스토리지 제한이 있습니다. 이 제한에 도달하면 오버플로는 두 번째 경로인 InnoDB on-disk 내부 임시 테이블(사용 가능한 경우)로 이동합니다. temptable_max_mmap의 경우 동적 파라미터이므로 인스턴스를 재부팅하지 않고도 변경할 수 있습니다.

디폴트 구성에는 오버플로가 두 과정을 거치도록 할 수 있습니다. 스토리지 할당이나 I/O 작업과 관련하여 두 과정에서 메모리 매핑 임시 파일이나 InnoDB 온디스크 내부 임시 테이블 중 하나만 사용하는 단일 과정에 비해 비용이 더 많이 들지만 둘 다 사용하지는 않습니다. temptable_max_mmap의 디폴트 값은 MySQL에서 1GB입니다. 이렇게 작은 디폴트 값으로 그대로 두게 되면 두 가지 경로를 사용할 가능성이 커집니다.

Amazon RDS for MySQL을 사용하는 경우 가능한 한 단일 홉 경로를 최적화하는 것이 좋습니다. 두 오버플로 경로 모두 DB 인스턴스에 연결된 동일한 스토리지로 연결됩니다. 메모리 매핑 임시 파일에 대한 스토리지가 부족한 경우 InnoDB 온디스크 내부 임시 테이블에도 동일하게 적용됩니다. 사용 가능한 여유 스토리지가 충분하다면 temptable_max_mmap값을 늘려서 워크로드에서 사용할 수 있는 최대 크기의 메모리 매핑 임시 파일을 저장하는 것이 좋습니다. 워크로드가 InnoDB 온디스크 내부 임시 테이블을 선호하는 경우 temptable_max_mmap을 0으로 설정하여 메모리 매핑 임시 파일 사용을 피할 수 있습니다. 스토리지를 확장하거나 워크로드를 조정하여 스토리지가 가득차는 것을 방지할 수 있습니다.

Aurora DB 클러스터의 Primary(Writer) DB 인스턴스에서 두 개의 오버플로 경로가 다른 스토리지 유형으로 이동하도록 할당됩니다. 메모리 매핑된 임시 파일(memory-mapped temporary file)은 로컬 스토리지에 생성됩니다. CloudWatch 메트릭 FreeLocalStorage를 사용하여 Aurora DB 인스턴스에서 사용 가능한 로컬 스토리지를 확인할 수 있으며, 이는 설정할 수 있는 temptable_max_mmap의 최대값입니다. InnoDB 온디스크 내부 임시 테이블은 128TiB 용량의 클러스터 볼륨 내에 저장됩니다. one-hop 경로가 여전히 가장 좋은 선택이며 워크로드에 가장 적합한 오버플로 경로를 선택할 수 있습니다. 주의해야 할 상황 중 하나는 클러스터 볼륨에서 지속적으로 증가되는 InnoDB 온디스크 내부 임시 테이블을 수행하는 폭주하는 쿼리입니다. 이 시나리오를 피하기 위해 max_execution_time을 구성하여 쿼리 시간 제한을 설정하는 것이 좋습니다.

Aurora 복제본(Reader) DB 인스턴스에서 TempTable은 내부 임시 테이블의 전용 스토리지 엔진이며, 오버플로 경로는 로컬 스토리지의 메모리 매핑된 임시 파일로만 이동합니다. temptable_max_mmap에서 설정한 저장 한도에 메모리 매핑된 임시 파일의 크기가 도달하면 “테이블이 가득 찼습니다”라는 오류 메시지와 함께 쿼리가 실패합니다. 워크로드에 따라 기본(Writer) DB 인스턴스와 복제본(Reader) DB 인스턴스에서 다른 임시 테이블 구성이 필요할 수 있으며, 인스턴스 수준에서 세부적인 조정을 보장하기 위해 별도의 DB 매개변수 그룹을 적용할 수 있습니다. 그러나 복제본(Reader) DB 인스턴스가 장애 조치 대상인 경우 장애 조치 후 잠재적인 불일치 문제를 방지하기 위해 기본(Writer) 및 복제본(Reader) DB 인스턴스가 동일한 인스턴스 클래스와 DB 파라미터 그룹을 사용하도록 구성하는 것이 좋습니다.

테이블 구조

TempTable 스토리지 엔진은 테이블에서 데이터를 검색하여 자체 형식으로 작업합니다. 처리할 데이터의 크기는 데이터 타입이나 캐릭터 셋과 같은 소스 테이블의 데이터 구조를 반영합니다. 다음 그래프는 테이블 캐릭터 셋과 다른 오버플로우 경로에 할당된 스토리지 간의 상관 관계의 예를 보여주고 있습니다.

데이터는 두 개의 Amazon RDS for MySQL DB 인스턴스에서 동일한 워크로드를 실행하여 수집됩니다. 각 인스턴스에는 10~100GB 크기의 sysbench 테이블 세트가 있습니다. 이 두 테이블 세트의 유일한 차이점은 한 세트가 디폴트 캐릭터 셋으로 latin1을 사용하고 다른 세트가 utf8mb4를 사용한다는 것입니다. 워크 로드에는 sysbench 테이블에 대해 하나씩 단일 GROUP BY 쿼리를 실행하는 것이 포함됩니다. 각 실행에서 TempTable 스토리지 엔진은 사용 가능한 모든 기본 1GB 메모리를 소비하고 one-hop 경로에서 오버플로우 됩니다.

테스트에서 다음을 관찰할 수 있습니다.

utf8mb4 캐릭터 셋을 사용하는 테이블과 latin1 캐릭터셋을 사용하는 테이블을 비교하면 오버플로우 경로와 관계없이 오버플로우 중에 할당된 스토리지에 큰 차이가 있음을 알 수 있습니다.
다른 오버플로우 경로도 차이에 영향을 미치며 utf8mb4 캐릭터 셋을 사용하는 테이블에서 그 차이가 더 커지는 경향이 있습니다.
모든 오버플로우 시나리오에서 테이블 크기에 일관되게 오버플로우 크기도 유사하게 증가하고 있습니다.

MySQL 8.0은 utf8mb4를 디폴트 캐릭터 셋으로 사용합니다. 이 변경의 잠재적 영향을 알고 테이블에 적합한 캐릭터 셋을 선택할 때 신중하게 고려해야 합니다.

RDS 스토리지 유형

TempTable 스토리지 엔진이 시스템 리소스를 얼마나 효율적으로 활용하는지에 대한 차이도 있습니다. 다음 다이어그램은 다양한 오버플로우 상황에서 쿼리 응답 시간과 RDS 스토리지 유형 간의 상관 관계의 예를 보여주고 있습니다. 테스트는 이전 테스트 환경에서 두 가지 추가 변경을 수행하여 수행됩니다. 첫째, 두 개의 RDS MySQL DB 인스턴스는 디폴트 캐릭터 셋으로 latin1을 사용하여 동일한 sysbench 테이블 세트를 로드합니다. 둘째, DB 인스턴스 중 하나는 1TB Amazon Elastic Block Store(Amazon EBS) 볼륨인 10k Provisioned IOPS(io1)로 구성되고 다른 하나는 General Purpose SSD(gp2)를 사용합니다. 이 1TB gp2 볼륨의 기준 성능은 3k IOPS입니다

위의 그래프에서 다음을 확인할 있습니다.

메모리 매핑 임시 파일(Memory-mapped Temporary File) 을 사용하면 쿼리가 처음에 io1 이나 gp2 볼륨에서 동일한 속도로 실행됩니다. 시간이 지남에 따라 gp2 볼륨의 버스팅 크레딧(Bursting Credit)이 소진되고 io1 볼륨의 쿼리가 더 나은 성능을 발휘하기 시작합니다.
오버플로우 경로가 InnoDB 온디스크 내부 임시 테이블을 사용하도록 변경되면 테이블 크기에 상관없이 다른 타입의 볼륨이 쿼리 응답 시간에 영향을 미치지 않습니다.
gp2 볼륨에서 실행되는 쿼리의 경우 InnoDB 온디스크 내부 임시 테이블이 메모리 매핑 임시 파일보다 더 나은 쿼리 응답 시간을 보일 수 있습니다.

Amazon RDS for MySQL을 사용하고 RDS 스토리지 유형을 선택할 수 있는 옵션이 있는 경우 high throughput Disk 스토리지를 사용하여 워크로드가 최적의 성능을 낼 수 있도록 도움을 받을 수 있습니다. Amazon Aurora MySQL DB 인스턴스에는 인스턴스 클래스에 따라 미리 구성된 로컬 스토리지 용량과 I/O 대역폭이 있습니다. 더 큰 인스턴스 클래스로 확장하여 더 많은 로컬 스토리지와 IOPS/처리량을 얻을 수 있습니다. TempTable 스토리지 엔진을 사용하여 대용량 데이터 세트를 처리하는 것을 방지하기 위해 쿼리를 조정하는 것이 항상 유용합니다.

모니터링

CloudWatch는 DB 인스턴스 레벨이나 DB 클러스터 레벨에서 메모리, 스토리지 사용량을 전반적으로 볼 수 있는 매트릭을 제공합니다. 다음의 매트릭이 대표적인 지표입니다.

Amazon RDS MySQL 이나 Aurora MySQL에서 FreeableMemory
Amazon RDS MySQL에서 FreeStorageSpace
Aurora MySQL에서 FreeLocalStorage, VolumeBytesUsed , AuroraVolumeBytesLeftTotal

DB 인스턴스에 Amazon RDS Performance Insights를 활성화하면 MySQL의 Performance Schema를 조회하여 TempTable 스토리지 엔진에서 사용하는 메모리나 스토리지를 모니터링할 수도 있습니다. 다음 SQL 쿼리를 사용하여 성능 스키마에서 유용한 정보를 얻을 수 있습니다.

-- DB 인스턴스 레벨에서 TempTable 스토리지 엔진의 메모리와 스토리지 사용량을 확인하기 위한 SQL 쿼리 

SELECT event_name, sum_number_of_bytes_alloc       
FROM performance_schema.memory_summary_global_by_event_name 
WHERE event_name like 'memory/temptable%';    

+--------------------------------+---------------------------+
| event_name                     | sum_number_of_bytes_alloc |
+--------------------------------+---------------------------+
| memory/temptable/physical_disk |                         0 |
| memory/temptable/physical_ram  |                 540016640 |
+--------------------------------+---------------------------+

-- 세션 레벨에서 메모리 맵 임시 파일의 사이즈를 확인할 수 있는 쿼리

SELECT event_name, sum_number_of_bytes_alloc     
FROM performance_schema.memory_summary_by_thread_by_event_name 
WHERE thread_id=( SELECT THREAD_ID FROM performance_schema.threads WHERE PROCESSLIST_ID=90)
ORDER BY sum_number_of_bytes_alloc desc limit 5;

+---------------------------------------+---------------------------+
| event_name                            | sum_number_of_bytes_alloc |
+---------------------------------------+---------------------------+
| memory/temptable/physical_disk        |                2684354560 |
| memory/sql/thd::main_mem_root         |                   1182416 |
| memory/mysqld_openssl/openssl_malloc  |                    150668 |
| memory/sql/Filesort_buffer::sort_keys |                     65536 |
| memory/sql/String::value              |                     34936 |
+---------------------------------------+---------------------------+

-- DB 인스턴스 레벨에서 InnoDB 내부 임시 테이블을 확인하는 SQL

SELECT * FROM INFORMATION_SCHEMA.INNODB_SESSION_TEMP_TABLESPACES;

+----+------------+----------------------------+------------+----------+-----------+
| ID | SPACE      | PATH                       | SIZE       | STATE    | PURPOSE   |
+----+------------+----------------------------+------------+----------+-----------+
| 69 | 4243767290 | ./#innodb_temp/temp_10.ibt |     163840 | ACTIVE   | INTRINSIC |
| 68 | 4243767289 | ./#innodb_temp/temp_9.ibt  |     163840 | ACTIVE   | INTRINSIC |
| 81 | 4243767287 | ./#innodb_temp/temp_7.ibt  |      81920 | ACTIVE   | INTRINSIC |
| 92 | 4243767288 | ./#innodb_temp/temp_8.ibt  | 4714397696 | ACTIVE   | INTRINSIC |
|  0 | 4243767281 | ./#innodb_temp/temp_1.ibt  |      81920 | INACTIVE | NONE      |
|  0 | 4243767282 | ./#innodb_temp/temp_2.ibt  |      81920 | INACTIVE | NONE      |
|  0 | 4243767283 | ./#innodb_temp/temp_3.ibt  |      81920 | INACTIVE | NONE      |
|  0 | 4243767284 | ./#innodb_temp/temp_4.ibt  |      81920 | INACTIVE | NONE      |
|  0 | 4243767285 | ./#innodb_temp/temp_5.ibt  |      81920 | INACTIVE | NONE      |
|  0 | 4243767286 | ./#innodb_temp/temp_6.ibt  |      81920 | INACTIVE | NONE      |
+----+------------+----------------------------+------------+----------+-----------+

요약

이 글에서는 Amazon RDS for MySQL DB 인스턴스와 Amazon Aurora MySQL DB 클러스터의 최적의 쿼리 성능을 위해 TempTable 스토리지 엔진을 구성하는 모범 사례에 대해서 알아보았습니다. 이 글을 통해 MySQL 8.0의 새로운 기능을 이해하는 데 도움이 되고 AWS의 관리형 데이터베이스 서비스에서 이를 쉽게 사용하는데 도움이 되기를 바랍니다.