정렬 인덱스 생성 - Amazon Aurora
지원되는 엔진 버전컨텍스트대기 증가의 가능한 원인작업

정렬 인덱스 생성

creating sort index 스레드 상태는 스레드가 데이터를 정렬하기 위해 내부 임시 테이블을 사용해야 하는 SELECT 문을 처리하고 있음을 나타냅니다.

지원되는 엔진 버전

이 스레드 상태 정보는 다음 버전에서 지원됩니다.

  • Aurora MySQL 버전 2에서 최대 2.09.2까지

컨텍스트

creating sort index 상태는 ORDER BY 또는 GROUP BY 절이 있는 쿼리가 기존 인덱스를 사용하여 작업을 수행할 수 없는 경우 표시됩니다. 이 경우 MySQL은 더 비싼 filesort 작업을 수행해야 합니다. 이 작업은 일반적으로 결과 집합이 너무 크지 않은 경우 메모리에서 수행됩니다. 그렇지 않은 경우 디스크에 파일을 만드는 작업이 포함됩니다.

대기 증가의 가능한 원인

creating sort index의 발생 그 자체로는 문제를 나타내지 않습니다. 성능이 좋지 않고 creating sort index 인스턴스가 자주 표시되는 경우 가장 가능성 있는 원인은 ORDER BY 또는 GROUP BY 연산자를 통한 속도가 느린 쿼리입니다.

작업

일반적인 지침은 creating sort index 상태의 증가와 연결된 ORDER BY 또는 GROUP BY 절이 있는 쿼리를 찾는 것입니다. 그런 다음 인덱스를 추가하거나 정렬 버퍼 크기를 늘리면 문제가 해결되는지 확인합니다.

성능 스키마가 켜져 있지 않으면 성능 스키마를 켭니다.

성능 개선 도우미는 성능 스키마 도구가 켜져 있지 않은 경우에만 스레드 상태를 보고합니다. 성능 스키마 도구가 켜져 있으면 성능 개선 도우미는 대신 대기 이벤트를 보고합니다. 성능 스키마 도구는 잠재적인 성능 문제를 조사하는 경우 추가적인 인사이트와 더 나은 도구를 제공합니다. 따라서 성능 스키마를 켜는 것이 좋습니다. 자세한 내용은 Aurora MySQL에서 성능 개선 도우미에 대해 성능 스키마 활성화 섹션을 참조하세요.

문제 쿼리 식별

creating sort index 상태의 증가를 일으키는 현재 쿼리를 식별하려면 show processlist를 실행한 다음 쿼리에 ORDER BY 또는 GROUP BY가 있는지 확인합니다. 선택적으로 N이 filesort가 있는 쿼리의 프로세스 목록 ID인 explain for connection N을 실행합니다.

이러한 증가를 유발하는 이전 쿼리를 식별하려면 느린 쿼리 로그를 켜고 ORDER BY로 해당 쿼리를 찾습니다. 느린 쿼리에서 EXPLAIN을 실행한 다음 'filesort 사용'을 찾으세요. 자세한 내용은 filesort 사용에 대한 설명 계획 검토 섹션을 참조하세요.

filesort 사용에 대한 설명 계획 검토

ORDER BY 또는 GROUP BY 절이 있는 명령문을 식별하면 creating sort index 상태로 됩니다.

다음 예에서는 쿼리에서 explain을 실행하는 방법을 보여줍니다. Extra 열은 이 쿼리가 filesort를 사용하는 것을 보여줍니다.

mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: mytable
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 2064548
     filtered: 100.00
        Extra: Using filesort
1 row in set, 1 warning (0.01 sec)

다음 예에서는 c1 열에 인덱스가 생성된 후 동일한 쿼리에서 EXPLAIN을 실행한 결과를 보여줍니다.

mysql> alter table mytable add index (c1);
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: mytable
   partitions: NULL
         type: index
possible_keys: NULL
          key: c1
      key_len: 1023
          ref: NULL
         rows: 10
     filtered: 100.00
        Extra: Using index
1 row in set, 1 warning (0.01 sec)

정렬 순서 최적화를 위한 인덱스 사용에 대한 자세한 내용은 MySQL 설명서의 ORDER BY 최적화를 참조하세요.

정렬 버퍼 크기 늘리기

특정 쿼리에 디스크에 파일을 만든 filesort 프로세스가 필요한지 여부를 확인하려면 쿼리를 실행한 후 sort_merge_passes 변수 값을 확인합니다. 다음은 그 한 예입니다.

mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Sort_merge_passes | 0     |
+-------------------+-------+
1 row in set (0.01 sec)

--- run query
mysql> select * from mytable order by u limit 10; 
--- run status again:

mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Sort_merge_passes | 0     |
+-------------------+-------+
1 row in set (0.01 sec)

sort_merge_passes의 값이 큰 경우 정렬 버퍼 크기를 늘리는 것이 좋습니다. 세션 수준에서 증가를 적용하세요. 전역적으로 늘리면 MySQL의 RAM 사용량이 크게 늘어날 수 있기 때문입니다. 다음 예에서는 쿼리를 실행하기 전에 정렬 버퍼 크기를 변경하는 방법을 보여줍니다.

mysql> set session sort_buffer_size=10*1024*1024;
Query OK, 0 rows affected (0.00 sec)
-- run query