Aurora MySQL 스레드 상태

스레드는 서버에 명령문을 실행하는 데 필요한 권한이 있는지 확인합니다.

서버는 현재 쿼리가 쿼리 캐시에 있는지 확인합니다.

이 상태는 작업이 완료되었지만 클라이언트에 의해 닫히지 않은 연결의 최종 상태입니다. 가장 좋은 해결책은 코드에서 연결을 명시적으로 닫는 것입니다. 또는 파라미터 그룹에서 wait_timeout에 대해 더 낮은 값을 설정할 수 있습니다.

스레드가 변경된 테이블 데이터를 디스크로 플러시하고 사용된 테이블을 닫습니다. 빠른 작업이 아닌 경우 인스턴스 클래스 네트워크 대역폭에 대해 네트워크 대역폭 사용 지표를 확인합니다. 또한 table_open_cache 및 table_definition_cache의 파라미터 값이 엔진이 테이블을 자주 열고 닫을 필요가 없도록 충분한 테이블을 동시에 열 수 있는지 확인합니다. 이러한 파라미터는 인스턴스의 메모리 사용에 영향을 줍니다.

쿼리는 임시 테이블을 인메모리에서 온디스크로 변환하고 있습니다. 쿼리 처리의 중간 단계에서 MySQL에서 만든 임시 테이블이 메모리에 비해 너무 커지기 때문에 이러한 변환이 필요합니다. tmp_table_size 및 max_heap_table_size의 값을 확인합니다. 이후 버전에서는 이 스레드 상태 이름은 converting HEAP to ondisk입니다.

스레드는 내부 임시 테이블을 인메모리 테이블에서 온디스크 테이블로 변환합니다.

스레드가 ALTER TABLE 문을 처리 중입니다. 이 상태는 새 구조의 테이블이 작성된 후 행이 이 테이블로 복사되기 전에 발생합니다. 이 상태의 스레드의 경우 성능 스키마를 사용하여 복사 작업의 진행률에 대한 정보를 얻을 수 있습니다.

Aurora MySQL은 기존 인덱스를 사용하여 쿼리의 ORDER BY 또는 GROUP BY 절을 충족시킬 수 없기 때문에 정렬을 수행합니다. 자세한 내용은 정렬 인덱스 생성 단원을 참조하십시오.

스레드가 영구 또는 임시 테이블을 생성 중입니다.

Aurora MySQL의 비동기 커밋이 승인을 받아 완료되었습니다.

Aurora MySQL 스레드는 비동기 커밋 프로세스를 시작했지만 승인을 기다리고 있습니다. 이 시간은 일반적으로 트랜잭션의 진정한 커밋 시간입니다.

응답이 클라이언트에 전송되는 동안 연결된 Aurora MySQL 작업자 스레드를 해제할 수 있습니다. 스레드는 다른 작업을 시작할 수 있습니다. delayed send ok 상태는 클라이언트에 대한 비동기 승인이 완료되었음을 의미합니다.

Aurora MySQL 작업자 스레드가 클라이언트에 비동기적으로 응답을 보냈으므로 이제 다른 연결에 대해 자유롭게 작업할 수 있습니다. 트랜잭션이 아직 승인되지 않은 비동기 커밋 프로세스를 시작했습니다.

스레드가 명령문을 실행하기 시작했습니다.

스레드가 명령을 실행했습니다. 이 상태에서 수행되는 항목의 일부 해제에는 쿼리 캐시가 포함됩니다. 이 상태는 일반적으로 정리됩니다.

이 상태는 ALTER TABLE, DELETE, INSERT, SELECT 또는 UPDATE 문의 초기화 전에 발생합니다. 이 상태의 작업에는 이진 로그 또는 InnoDB 로그의 플러시 및 쿼리 캐시의 일부 정리가 포함됩니다.

주 노드가 복제의 일부를 완료했습니다. 스레드는 이진 로그(binlog)에 쓸 수 있도록 더 많은 쿼리가 실행되기를 기다리고 있습니다.

스레드가 테이블을 열려고 합니다. 이 작업은 ALTER TABLE 또는 LOCK TABLE 문이 table_open_cache 값을 완료해야 하거나 초과하지 않는 한 빠르게 수행됩니다.

서버가 쿼리에 대해 초기 최적화를 수행 중입니다.

이 상태는 쿼리 최적화 중에 발생합니다.

이 상태는 쿼리 처리 후 항목 해제 상태 전에 발생합니다.

Aurora MySQL은 쿼리의 초기 단계에서 DISTINCT 작업을 최적화 할 수 없습니다. Aurora MySQL은 결과를 클라이언트에 보내기 전에 중복된 행을 모두 제거해야 합니다.

스레드는 업데이트하기 전에 일치하는 모든 행을 찾습니다. 이 단계는 UPDATE가 엔진이 행을 찾는 데 사용하는 인덱스를 변경하는 경우 필요합니다.

스레드는 이진 로그에서 이벤트를 읽은 다음 복제본으로 보냅니다.

서버가 쿼리 캐시에서 쿼리 결과를 가져와 클라이언트로 보냅니다.

스레드가 SELECT 문에 대한 행을 읽고 처리하고 있지만 아직 클라이언트로 데이터 전송을 시작하지 않았습니다. 이 프로세스는 쿼리를 충족하는 데 필요한 결과가 포함된 페이지를 식별하는 것입니다. 자세한 내용은 데이터 전송 단원을 참조하십시오.

서버가 클라이언트에 패킷을 쓰고 있습니다. 이전 MySQL 버전에서 이 대기 이벤트에 writing to net의 레이블이 지정되었습니다.

이 단계는 명령문 실행 시작의 첫 번째 단계입니다.

서버는 쿼리 실행 계획을 개발하기 위해 통계를 계산하고 있습니다. 스레드가 오랫동안 이 상태인 경우 서버가 다른 작업을 수행하는 동안 디스크 바인딩될 수 있습니다.

서버가 쿼리 캐시에 쿼리 결과를 저장하고 있습니다.

스레드가 mysql_lock_tables를 호출했지만 호출 이후 스레드 상태가 업데이트되지 않았습니다. 이 일반적인 상태는 여러 가지 이유로 발생합니다.

스레드가 테이블 업데이트를 시작하기 위해 준비 중입니다.

스레드가 행을 검색하고 업데이트하고 있습니다.

스레드가 GET_LOCK 호출을 실행했습니다. 스레드는 자문 잠금을 요청하고 기다리고 있거나 자문 잠금을 요청할 계획입니다.

주 노드가 복제의 일부를 완료했습니다. 스레드는 이진 로그(binlog)에 쓸 수 있도록 더 많은 쿼리가 실행되기를 기다리고 있습니다.

메타데이터 잠금을 기다리는 것입니다.

메타데이터 잠금을 기다리는 것입니다.

메타데이터 잠금을 기다리는 것입니다.

스레드는 FLUSH TABLES를 실행 중이며 모든 스레드에서 해당 테이블을 닫을 때까지 대기하고 있습니다. 또는 스레드는 테이블의 기본 구조가 변경되었다는 알림을 받았으므로 테이블을 다시 열어 새 구조를 가져와야 합니다. 테이블을 다시 열려면 스레드는 다른 모든 스레드에서 테이블을 닫을 때까지 기다려야 합니다. 이 알림은 다른 스레드가 테이블에서 FLUSH TABLES, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE 또는 OPTIMIZE TABLE 문 중 하나를 사용한 경우 발생합니다.

한 세션은 테이블에서 잠금을 유지하는 반면 다른 세션은 동일한 테이블에서 동일한 잠금을 가져오려고 시도합니다.

Aurora MySQL은 메타데이터 잠금을 사용하여 데이터베이스 객체에 대한 동시 액세스를 관리하고 데이터 일관성을 보장합니다. 이 대기 이벤트에서 한 세션은 테이블에서 메타데이터 잠금을 유지하는 반면 다른 세션은 동일한 테이블에서 동일한 잠금을 가져오려고 시도합니다. 성능 스키마가 사용 설정되면 이 스레드 상태는 synch/cond/sql/MDL_context::COND_wait_status 대기 이벤트로 보고됩니다.

서버가 네트워크에 패킷을 쓰고 있습니다. MySQL 이후 버전에서 이 대기 이벤트에 Sending to client의 레이블이 지정됩니다.