# 정렬 인덱스 생성
`creating sort index` 스레드 상태는 스레드가 데이터를 정렬하기 위해 내부 임시 테이블을 사용해야 하는 `SELECT` 문을 처리하고 있음을 나타냅니다.
**Topics**
+ [지원되는 엔진 버전](#ams-states.sort-index.context.supported)
+ [컨텍스트](#ams-states.sort-index.context)
+ [대기 증가의 가능한 원인](#ams-states.sort-index.causes)
+ [작업](#ams-states.sort-index.actions)
## 지원되는 엔진 버전
이 스레드 상태 정보는 다음 버전에서 지원됩니다.
+ 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` 절이 있는 쿼리를 찾는 것입니다. 그런 다음 인덱스를 추가하거나 정렬 버퍼 크기를 늘리면 문제가 해결되는지 확인합니다.
**Topics**
+ [성능 스키마가 켜져 있지 않으면 성능 스키마를 켭니다.](#ams-states.sort-index.actions.enable-pfs)
+ [문제 쿼리 식별](#ams-states.sort-index.actions.identify)
+ [filesort 사용에 대한 설명 계획 검토](#ams-states.sort-index.actions.plan)
+ [정렬 버퍼 크기 늘리기](#ams-states.sort-index.actions.increasebuffersize)
### 성능 스키마가 켜져 있지 않으면 성능 스키마를 켭니다.
성능 개선 도우미는 성능 스키마 도구가 켜져 있지 않은 경우에만 스레드 상태를 보고합니다. 성능 스키마 도구가 켜져 있으면 성능 개선 도우미는 대신 대기 이벤트를 보고합니다. 성능 스키마 도구는 잠재적인 성능 문제를 조사하는 경우 추가적인 인사이트와 더 나은 도구를 제공합니다. 따라서 성능 스키마를 켜는 것이 좋습니다. 자세한 내용은 [Aurora MySQL에서 성능 개선 도우미의 성능 스키마 개요](USER_PerfInsights.EnableMySQL.md) 섹션을 참조하세요.
### 문제 쿼리 식별
`creating sort index` 상태의 증가를 일으키는 현재 쿼리를 식별하려면 `show processlist`를 실행한 다음 쿼리에 `ORDER BY` 또는 `GROUP BY`가 있는지 확인합니다. 선택적으로 `N`이 `filesort`가 있는 쿼리의 프로세스 목록 ID인 `explain for connection N`을 실행합니다.
이러한 증가를 유발하는 이전 쿼리를 식별하려면 느린 쿼리 로그를 켜고 `ORDER BY`로 해당 쿼리를 찾습니다. 느린 쿼리에서 `EXPLAIN`을 실행한 다음 'filesort 사용'을 찾으세요. 자세한 내용은 [filesort 사용에 대한 설명 계획 검토](#ams-states.sort-index.actions.plan) 섹션을 참조하세요.
### 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 최적화](https://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html)를 참조하세요.
### 정렬 버퍼 크기 늘리기
특정 쿼리에 디스크에 파일을 만든 `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
```