데이터 전송

sending data 스레드 상태는 스레드가 올바른 결과 집합을 결정하기 위해 쿼리의 행을 읽고 필터링하고 있음을 나타냅니다. 이름은 상태가 나중에 전송할 데이터를 수집 및 준비하지 않고 데이터를 전송하고 있음을 의미하기 때문에 오해의 소지가 있습니다.

지원되는 엔진 버전

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

컨텍스트

대부분 스레드 상태는 오래 지속되지 않습니다. sending data 도중 발생하는 작업은 많은 수의 디스크 또는 캐시 읽기를 수행하는 경향이 있습니다. 따라서 sending data는 주어진 쿼리의 수명 동안 가장 긴 실행 상태인 경우가 많습니다. 이 상태는 Aurora MySQL에서 다음을 수행할 때 표시됩니다.

sending data 상태가 데이터 준비를 완료한 다음의 writing to net 스레드 상태는 클라이언트로 데이터 반환을 나타냅니다. 일반적으로 writing to net은 결과 집합이 매우 크거나 네트워크 대기 시간이 심각해 전송 속도가 느려지는 경우에만 캡처됩니다.

대기 증가의 가능한 원인

sending data의 발생 그 자체로는 문제를 나타내지 않습니다. 성능이 좋지 않고 sending data 인스턴스가 자주 표시되는 경우 가장 가능성 있는 원인은 다음과 같습니다.

비효율적인 쿼리

대부분의 경우 이 상태를 담당하는 것은 특정 쿼리의 결과 집합을 찾기 위해 적절한 인덱스를 사용하지 않는 쿼리입니다. 예를 들어 상태 열이 인덱싱되지 않거나 제대로 인덱싱되지 않은 캘리포니아에 배치된 모든 주문에 대해 1천만 개의 레코드 테이블을 읽는 쿼리를 가정해 보겠습니다. 후자의 경우 인덱스가 존재할 수도 있지만 최적화 프로그램은 카디널리티가 낮아 인덱스를 무시합니다.

최적이 아닌 서버 구성

sending data 상태에 여러 쿼리가 표시되는 경우 데이터베이스 서버가 제대로 구성되지 않을 수 있습니다. 특히 서버에 다음과 같은 문제가 있을 수 있습니다.

작업

일반적인 지침은 성능 스키마를 확인하여 많은 수의 행을 반환하는 쿼리를 찾는 것입니다. 인덱스를 사용하지 않는 로깅 쿼리가 켜져 있는 경우 느린 로그의 결과를 검사할 수도 있습니다.

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

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

메모리 설정 검사

기본 버퍼 풀의 메모리 설정을 검사합니다. 이러한 풀의 크기가 워크로드에 적절한지 확인합니다. 데이터베이스에서 여러 버퍼 풀 인스턴스를 사용하는 경우 여러 개의 작은 버퍼 풀로 분할되지 않았는지 확인합니다. 스레드는 한 번에 하나의 버퍼 풀만 사용할 수 있습니다.

각 스레드에 사용되는 다음 메모리 설정의 크기가 적절한지 확인합니다.

설정을 수정할 특별한 이유가 없는 한 기본값을 사용합니다.

인덱스 사용량에 대한 설명 계획 검토

sending data 스레드 상태에 대한 쿼리의 경우 계획을 검토하여 적절한 인덱스가 사용되는지 확인합니다. 쿼리가 유용한 인덱스를 사용하지 않는 경우 USE INDEX 또는 FORCE INDEX와 같은 힌트를 추가하는 것이 좋습니다. 힌트는 쿼리를 실행하는 데 걸리는 시간을 크게 늘리거나 줄일 수 있으므로 추가하기 전에 주의해야 합니다.

반환된 데이터의 양 확인

쿼리되는 테이블과 테이블에 포함된 데이터의 양을 확인합니다. 이 데이터를 모두 아카이브할 수 있나요? 대부분의 경우 부족한 쿼리 실행 시간의 원인은 쿼리 계획의 결과가 아니라 처리할 데이터 볼륨입니다. 많은 개발자가 데이터베이스에 데이터를 매우 효율적으로 추가하지만, 설계 및 개발 단계에서는 데이터 세트 수명 주기를 거의 고려하지 않습니다.

작은 볼륨의 데이터베이스에서는 잘 수행되지만 현재 시스템에서는 제대로 수행되지 않는 쿼리를 찾습니다. 특정 쿼리를 설계하는 개발자는 때로는 이러한 쿼리가 350,000개의 행을 반환한다는 사실을 인식하지 못할 수도 있습니다. 개발자는 프로덕션 환경보다 작은 데이터 세트를 사용하여 볼륨이 작은 환경에서 쿼리를 개발했을 수 있습니다.

동시성 문제 확인

동일한 유형의 여러 쿼리가 동시에 실행되고 있는지 확인합니다. 일부 형식의 쿼리는 단독으로 실행될 때 효율적으로 실행됩니다. 그러나 유사한 형식의 쿼리가 함께 실행되거나 많은 볼륨으로 실행되면 동시성 문제가 발생할 수 있습니다. 데이터베이스가 임시 테이블을 사용하여 결과를 렌더링할 때 이러한 문제가 발생하는 경우가 많습니다. 제한적인 트랜잭션 격리 수준은 동시성 문제를 일으킬 수도 있습니다.

테이블을 동시에 읽고 쓰는 경우 데이터베이스가 잠금을 사용하고 있을 수 있습니다. 성능 저하 기간을 식별하려면 대규모 배치 프로세스를 통해 데이터베이스 사용을 검토합니다. 최근 잠금 및 롤백을 확인하려면 SHOW ENGINE INNODB STATUS 명령의 결과를 검토합니다.

요청 구조 확인

이러한 상태에서 캡처된 쿼리가 하위 쿼리를 사용하는지 확인합니다. 이러한 유형의 쿼리는 데이터베이스가 내부적으로 결과를 컴파일한 다음 데이터를 렌더링하기 위해 쿼리로 다시 대체하기 때문에 성능이 저하되는 경우가 많습니다. 이 프로세스는 데이터베이스에 대한 추가 단계입니다. 대부분의 경우 이 단계는 동시 로드 조건에서 성능이 저하될 수 있습니다.

또한 쿼리가 많은 수의 ORDER BY 및 GROUP BY 절을 사용하는지 확인합니다. 이러한 작업에서는 데이터베이스가 먼저 메모리에 전체 데이터 세트를 구성해야 하는 경우가 많습니다. 그런 다음 클라이언트로 반환하기 전에 특정 방식으로 주문하거나 그룹화해야 합니다.